deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-37915
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

net_sched: drr: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem
child qdisc will make the parent qdisc's enqueue callback reentrant.
In the case of drr, there won't be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether the
class was already added to the active_list (cl_is_active) before adding
to the list to cover for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
CVSS Score: 7.0 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/26e75716b94d6ff9be5ea07d63675c4d189f30b4; https://git.kernel.org/stable/c/[PII_REDACTED]f1792007eedd12eeedf7f6e2b7e9f3; https://git.kernel.org/stable/c/4b07ac06b0a712923255aaf[PII_REDACTED]fc7100d
CVE: CVE-2025-37916
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

pds_core: remove write-after-free of client_id

A use-after-free error popped up in stress testing:

[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core]
[Mon Apr 21 21:21:33 2025] Use-after-free write at 0x[PII_REDACTED]13ecd1 (in kfence-#47):
[Mon Apr 21 21:21:33 2025]  pdsc_auxbus_dev_del+0xef/0x160 [pds_core]
[Mon Apr 21 21:21:33 2025]  pdsc_remove+0xc0/0x1b0 [pds_core]
[Mon Apr 21 21:21:33 2025]  pci_device_remove+0x24/0x70
[Mon Apr 21 21:21:33 2025]  device_release_driver_internal+0x11f/0x180
[Mon Apr 21 21:21:33 2025]  driver_detach+0x45/0x80
[Mon Apr 21 21:21:33 2025]  bus_remove_driver+0x83/0xe0
[Mon Apr 21 21:21:33 2025]  pci_unregister_driver+0x1a/0x80

The actual device uninit usually happens on a separate thread
scheduled after this code runs, but there is no guarantee of order
of thread execution, so this could be a problem.  There's no
actual need to clear the client_id at this point, so simply
remove the offending code.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/26dc701021302f11c[PII_REDACTED]d11763bd81dfe; https://git.kernel.org/stable/c/9b467c5bcdb45a41d2a49fbb9ffca73d1380e99b; https://git.kernel.org/stable/c/c649b9653ed09196e91d3f4b16b679041b3c42e6
CVE: CVE-2025-37917
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll

Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock
and spin_unlock in mtk_star_emac driver to avoid spinlock recursion
occurrence that can happen when enabling the DMA interrupts again in
rx/tx poll.

```
BUG: spinlock recursion on CPU#0, swapper/0/0
 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0,
    .owner_cpu: 0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
    6.15.0-rc2-next-20[PII_REDACTED]1-gf6a27738686c-dirty #28 PREEMPT
Hardware name: MediaTek MT8365 Open Platform EVK (DT)
Call trace:
 show_stack+0x18/0x24 (C)
 dump_stack_lvl+0x60/0x80
 dump_stack+0x18/0x24
 spin_dump+0x78/0x88
 do_raw_spin_lock+0x11c/0x120
 _raw_spin_lock+0x20/0x2c
 mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac]
 __handle_irq_event_percpu+0x48/0x140
 handle_irq_event+0x4c/0xb0
 handle_fasteoi_irq+0xa0/0x1bc
 handle_irq_desc+0x34/0x58
 generic_handle_domain_irq+0x1c/0x28
 gic_handle_irq+0x4c/0x120
 do_interrupt_handler+0x50/0x84
 el1_interrupt+0x34/0x68
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x6c/0x70
 regmap_mmio_read32le+0xc/0x20 (P)
 _regmap_bus_reg_read+0x6c/0xac
 _regmap_read+0x60/0xdc
 regmap_read+0x4c/0x80
 mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac]
 __napi_poll+0x38/0x188
 net_rx_action+0x164/0x2c0
 handle_softirqs+0x100/0x244
 __do_softirq+0x14/0x20
 ____do_softirq+0x10/0x20
 call_on_irq_stack+0x24/0x64
 do_softirq_own_stack+0x1c/0x40
 __irq_exit_rcu+0xd4/0x10c
 irq_exit_rcu+0x10/0x1c
 el1_interrupt+0x38/0x68
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x6c/0x70
 cpuidle_enter_state+0xac/0x320 (P)
 cpuidle_enter+0x38/0x50
 do_idle+0x1e4/0x260
 cpu_startup_entry+0x34/0x3c
 rest_init+0xdc/0xe0
 console_on_rootfs+0x0/0x6c
 __primary_switched+0x88/0x90
```
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6fe[PII_REDACTED]736cc3ba1c6fd4606d3dbe55c9c; https://git.kernel.org/stable/c/7cb10f17bddc415f30fbc00a4e2b490e0d94c462; https://git.kernel.org/stable/c/8d40bf73fa7f31eac2b0a7c9d85de67df82ee7f3
CVE: CVE-2025-37918
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()

A NULL pointer dereference can occur in skb_dequeue() when processing a
QCA firmware crash dump on WCN7851 (0489:e0f3).

[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)

[ 93.672475] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]
[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80

The issue stems from handle_dump_pkt_qca() returning 0 even when a dump
packet is successfully processed. This is because it incorrectly
forwards the return value of hci_devcd_init() (which returns 0 on
success). As a result, the caller (btusb_recv_acl_qca() or
btusb_recv_evt_qca()) assumes the packet was not handled and passes it
to hci_recv_frame(), leading to premature kfree() of the skb.

Later, hci_devcd_rx() attempts to dequeue the same skb from the dump
queue, resulting in a NULL pointer dereference.

Fix this by:
1. Making handle_dump_pkt_qca() return 0 on success and negative errno
   on failure, consistent with kernel conventions.
2. Splitting dump packet detection into separate functions for ACL
   and event packets for better structure and readability.

This ensures dump packets are properly identified and consumed, avoiding
double handling and preventing NULL pointer access.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0317b033abcd1d8dd2798f0e2de5e84543d0bd22; https://git.kernel.org/stable/c/2e8d44ebaa7babdd5c5ab50ca275826e241920d6; https://git.kernel.org/stable/c/8563d9fabd8a4b726ba7acab4737c438bf11a059
CVE: CVE-2025-37919
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot

Update chip data using dev_get_drvdata(dev->parent) to fix
NULL pointer deref in acp_i2s_set_tdm_slot.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3104b7d559ffb28f34e55028ff55a475e26e2e1e; https://git.kernel.org/stable/c/6d9b64156d849e358cb49b6b899fb0b7d262bda8; https://git.kernel.org/stable/c/fd4d8d139030dd2de97ef46d332673675ca8ad72
CVE: CVE-2025-37920
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

xsk: Fix race condition in AF_XDP generic RX path

Move rx_lock from xsk_socket to xsk_buff_pool.
Fix synchronization for shared umem mode in
generic RX path where multiple sockets share
single xsk_buff_pool.

RX queue is exclusive to xsk_socket, while FILL
queue can be shared between multiple sockets.
This could result in race condition where two
CPU cores access RX path of two different sockets
sharing the same umem.

Protect both queues by acquiring spinlock in shared
xsk_buff_pool.

Lock contention may be minimized in the future by some
per-thread FQ buffering.

It's safe and necessary to move spin_lock_bh(rx_lock)
after xsk_rcv_check():
* xs->pool and spinlock_init is synchronized by
  xsk_bind() -> xsk_is_bound() memory barriers.
* xsk_rcv_check() may return true at the moment
  of xsk_release() or xsk_unbind_dev(),
  however this will not cause any data races or
  race conditions. xsk_unbind_dev() removes xdp
  socket from all maps and waits for completion
  of all outstanding rx operations. Packets in
  RX path will either complete safely or drop.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/65d3c570614b892257dc58a1b202908242ecf8fd; https://git.kernel.org/stable/c/75a240a3e8abf17b9e00b0ef0492b1bbaa932251; https://git.kernel.org/stable/c/975b372313dc018b9bd6cc0d85d188787054b19e
CVE: CVE-2025-37921
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

vxlan: vnifilter: Fix unlocked deletion of default FDB entry

When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").

Reproducer:

 # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
 # bridge vni del vni 10010 dev vx0

Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.

[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
 <TASK>
 __vxlan_fdb_delete+0xbe/0x560
 vxlan_vni_delete_group+0x2ba/0x940
 vxlan_vni_del.isra.0+0x15f/0x580
 vxlan_process_vni_filter+0x38b/0x7b0
 vxlan_vnifilter_process+0x3bb/0x510
 rtnetlink_rcv_msg+0x2f7/0xb70
 netlink_rcv_skb+0x131/0x360
 netlink_unicast+0x426/0x710
 netlink_sendmsg+0x75a/0xc20
 __sock_sendmsg+0xc1/0x150
 ____sys_sendmsg+0x5aa/0x7b0
 ___sys_sendmsg+0xfc/0x180
 __sys_sendmsg+0x121/0x1b0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/087a9eb9e5978e3ba362e1163691e41097e8ca20; https://git.kernel.org/stable/c/2d4a121296aa3940d2df9906f955c2b6b4e38bc3; https://git.kernel.org/stable/c/3576e9a80b6c4381b01ce0cbaa07f5e92d4492ed
CVE: CVE-2025-37923
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix oob write in trace_seq_to_buffer()

syzbot reported this bug:
==================================================================
BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260

CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:408 [inline]
 print_report+0xc3/0x670 mm/kasan/report.c:521
 kasan_report+0xe0/0x110 mm/kasan/report.c:634
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106
 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
 tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
 ....
==================================================================

It has been reported that trace_seq_to_buffer() tries to copy more data
than PAGE_SIZE to buf. Therefore, to prevent this, we should use the
smaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/056ebbddb8faf4ddf83d005454dd78fc25c2d897; https://git.kernel.org/stable/c/1a3f9482b50b74fa9421bff8ceecfefd0dc06f8f; https://git.kernel.org/stable/c/1f27a3e93b8d674b24b27fcdbc6f72743cd96c0d
CVE: CVE-2025-37924
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in kerberos authentication

Setting sess->user = NULL was introduced to fix the dangling pointer
created by ksmbd_free_user. However, it is possible another thread could
be operating on the session and make use of sess->user after it has been
passed to ksmbd_free_user but before sess->user is set to NULL.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-416
References: https://git.kernel.org/stable/c/28c756738af44a404a91b77830d017bb0c525890; https://git.kernel.org/stable/c/b[PII_REDACTED]38428503cfba1c[PII_REDACTED]72f90; https://git.kernel.org/stable/c/e18c616718018dfc440e4a2d2b94e28fe91b1861
CVE: CVE-2025-37926
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in ksmbd_session_rpc_open

A UAF issue can occur due to a race condition between
ksmbd_session_rpc_open() and __session_rpc_close().
Add rpc_lock to the session to protect it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1067361a1cc6ad9cdf7acfc47f90012b72ad1502; https://git.kernel.org/stable/c/6323fec65fe54b365961fed260dd579191e46121; https://git.kernel.org/stable/c/8fb3b6c85b7e[PII_REDACTED]586b62abcc366caa20
CVE: CVE-2025-37927
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid

There is a string parsing logic error which can lead to an overflow of hid
or uid buffers. Comparing ACPIID_LEN against a total string length doesn't
take into account the lengths of individual hid and uid buffers so the
check is insufficient in some cases. For example if the length of hid
string is 4 and the length of the uid string is 260, the length of str
will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer
which size is 256.

The same applies to the hid string with length 13 and uid string with
length 250.

Check the length of hid and uid strings separately to prevent
buffer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/10d901a95f8e766e5aa0bb9a983fb41271f64718; https://git.kernel.org/stable/c/13d67528e1ae4486e9ab24b70122fab104c73c29; https://git.kernel.org/stable/c/2b65060c84ee4d8dc64fae6d2728b528e9e832e1
CVE: CVE-2025-37929
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: errata: Add missing sentinels to Spectre-BHB MIDR arrays

Commit a5951389e58d ("arm64: errata: Add newer ARM cores to the
spectre_bhb_loop_affected() lists") added some additional CPUs to the
Spectre-BHB workaround, including some new arrays for designs that
require new 'k' values for the workaround to be effective.

Unfortunately, the new arrays omitted the sentinel entry and so
is_midr_in_range_list() will walk off the end when it doesn't find a
match. With UBSAN enabled, this leads to a crash during boot when
is_midr_in_range_list() is inlined (which was more common prior to
c8c2647e69be ("arm64: Make  _midr_in_range_list() an exported
function")):

 |  Internal error: aarch64 BRK: 00000000f2000001 [#1] PREEMPT SMP
 |  pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 |  pc : spectre_bhb_loop_affected+0x28/0x30
 |  lr : is_spectre_bhb_affected+0x170/0x190
 | [...]
 |  Call trace:
 |   spectre_bhb_loop_affected+0x28/0x30
 |   update_cpu_capabilities+0xc0/0x184
 |   init_cpu_features+0x188/0x1a4
 |   cpuinfo_store_boot_cpu+0x4c/0x60
 |   smp_prepare_boot_cpu+0x38/0x54
 |   start_kernel+0x8c/0x478
 |   __primary_switched+0xc8/0xd4
 |  Code: 6b09011f [PII_REDACTED] d65f03c0 (d4200020)
 |  ---[ end trace [PII_REDACTED] ]---
 |  Kernel panic - not syncing: aarch64 BRK: Fatal exception

Add the missing sentinel entries.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/090c8714efe1c3c470301cc2f794c1ee2a57746c; https://git.kernel.org/stable/c/333579202f09e260e8116321df4c55f80a19b160; https://git.kernel.org/stable/c/3821cae9bd5a99a42d3d0be1b58e41f072cd4c4c
CVE: CVE-2025-37930
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()

Nouveau is mostly designed in a way that it's expected that fences only
ever get signaled through nouveau_fence_signal(). However, in at least
one other place, nouveau_fence_done(), can signal fences, too. If that
happens (race) a signaled fence remains in the pending list for a while,
until it gets removed by nouveau_fence_update().

Should nouveau_fence_context_kill() run in the meantime, this would be
a bug because the function would attempt to set an error code on an
already signaled fence.

Have nouveau_fence_context_kill() check for a fence being signaled.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/[PII_REDACTED]ecc816ec15c736e52316f69db0deb9; https://git.kernel.org/stable/c/126f5c6e0cb84e5c6f7a3a856d799d85668fb38e; https://git.kernel.org/stable/c/2ec0f5f6d4768f292c8406ed92fa699f184577e5
CVE: CVE-2025-37931
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: adjust subpage bit start based on sectorsize

When running machines with 64k page size and a 16k nodesize we started
seeing tree log corruption in production.  This turned out to be because
we were not writing out dirty blocks sometimes, so this in fact affects
all metadata writes.

When writing out a subpage EB we scan the subpage bitmap for a dirty
range.  If the range isn't dirty we do

	bit_start++;

to move onto the next bit.  The problem is the bitmap is based on the
number of sectors that an EB has.  So in this case, we have a 64k
pagesize, 16k nodesize, but a 4k sectorsize.  This means our bitmap is 4
bits for every node.  With a 64k page size we end up with 4 nodes per
page.

To make this easier this is how everything looks

[0         16k       32k       48k     ] logical address
[0         4         8         12      ] radix tree offset
[               64k page               ] folio
[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers
[ | | | |  | | | |   | | | |   | | | | ] bitmap

Now we use all of our addressing based on fs_info->sectorsize_bits, so
as you can see the above our 16k eb->start turns into radix entry 4.

When we find a dirty range for our eb, we correctly do bit_start +=
sectors_per_node, because if we start at bit 0, the next bit for the
next eb is 4, to correspond to eb->start 16k.

However if our range is clean, we will do bit_start++, which will now
put us offset from our radix tree entries.

In our case, assume that the first time we check the bitmap the block is
not dirty, we increment bit_start so now it == 1, and then we loop
around and check again.  This time it is dirty, and we go to find that
start using the following equation

	start = folio_start + bit_start * fs_info->sectorsize;

so in the case above, eb->start 0 is now dirty, and we calculate start
as

	0 + 1 * fs_info->sectorsize = 4096
	4096 >> 12 = 1

Now we're looking up the radix tree for 1, and we won't find an eb.
What's worse is now we're using bit_start == 1, so we do bit_start +=
sectors_per_node, which is now 5.  If that eb is dirty we will run into
the same thing, we will look at an offset that is not populated in the
radix tree, and now we're skipping the writeout of dirty extent buffers.

The best fix for this is to not use sectorsize_bits to address nodes,
but that's a larger change.  Since this is a fs corruption problem fix
it simply by always using sectors_per_node to increment the start bit.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/396f[PII_REDACTED]ea1cfd4c789ebaf0a6969ab34f; https://git.kernel.org/stable/c/5111b148360f50cac9abbae8fca44cc0ac4bf9bf; https://git.kernel.org/stable/c/977849e8acd2466ac3cb49e04a3ecc73837f6b90
CVE: CVE-2025-37932
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

sch_htb: make htb_qlen_notify() idempotent

htb_qlen_notify() always deactivates the HTB class and in fact could
trigger a warning if it is already deactivated. Therefore, it is not
idempotent and not friendly to its callers, like fq_codel_dequeue().

Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers'
life.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0a188c0e197383683fd093ab1ea6ce9a5869a6ea; https://git.kernel.org/stable/c/32ae12ce6a9f6bace186ca7335220ff59b6cc3cd; https://git.kernel.org/stable/c/5ba8b837b522d7051ef81bacf3d95383ff8edce5
CVE: CVE-2025-37933
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: Fix host hang issue during device reboot

When the host loses heartbeat messages from the device,
the driver calls the device-specific ndo_stop function,
which frees the resources. If the driver is unloaded in
this scenario, it calls ndo_stop again, attempting to free
resources that have already been freed, leading to a host
hang issue. To resolve this, dev_close should be called
instead of the device-specific stop function.dev_close
internally calls ndo_stop to stop the network interface
and performs additional cleanup tasks. During the driver
unload process, if the device is already down, ndo_stop
is not called.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-415
References: https://git.kernel.org/stable/c/34f42736b325287a7b2ce37e415838f539767bda; https://git.kernel.org/stable/c/6d[PII_REDACTED]e7d0aece9af5e77bbc324face8f1; https://git.kernel.org/stable/c/7e1ca1bed3f66e00377f7d2147be[PII_REDACTED]76
CVE: CVE-2025-37934
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: simple-card-utils: Fix pointer check in graph_util_parse_link_direction

Actually check if the passed pointers are valid, before writing to them.
This also fixes a USBAN warning:
UBSAN: invalid-load in ../sound/soc/fsl/imx-card.c:687:25
load of value 255 is not a valid value for type '_Bool'

This is because playback_only is uninitialized and is not written to, as
the playback-only property is absent.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/3cc393d2232ec770b5f79bf0673d67702a3536c3; https://git.kernel.org/stable/c/9b5b3088c4d[PII_REDACTED]05919bd7d067964288; https://git.kernel.org/stable/c/b41a49d5435e0f76da320f231b7252800e8f736f
CVE: CVE-2025-37935
Published: 2025-05-20
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAM

If the mtk_poll_rx() function detects the MTK_RESETTING flag, it will
jump to release_desc and refill the high word of the SDP on the 4GB RFB.
Subsequently, mtk_rx_clean will process an incorrect SDP, leading to a
panic.

Add patch from MediaTek's SDK to resolve this.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/317013d1ad13524be02d60b9e98f08fbd13f8c14; https://git.kernel.org/stable/c/67619cf69dec5d1d7792808dfa548616742dd51d; https://git.kernel.org/stable/c/6e0490fc36cdac696f96e57b61d93b9ae32e0f4c