The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

jfs: add check read-only before txBeginAnon() call

Added a read-only check before calling txBeginAnon in extAlloc and extRecord. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes.

Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfsextent.c:78 jfsgetblock+0x340/0xb98 fs/jfs/inode.c:248 _blockwritebeginint+0x580/0x166c fs/buffer.c:2128 _blockwritebegin fs/buffer.c:2177 [inline] blockwritebegin+0x98/0x11c fs/buffer.c:2236 jfswritebegin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)

In the Linux kernel, the following vulnerability has been resolved:

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswapcompress() and zswapdecompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.

Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.

The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.

Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2].

Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.

[1]https://lkml.kernel.org/(CVE-2025-21693)

In the Linux kernel, the following vulnerability has been resolved:

memstick: rtsxusbms: Fix slab-use-after-free in rtsxusbmsdrvremove

This fixes the following crash:

================================================================== BUG: KASAN: slab-use-after-free in rtsxusbmspollcard+0x159/0x200 [rtsxusbms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241

CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNEDMODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsxusbmspollcard [rtsxusbms] Call Trace: <TASK> dumpstacklvl+0x51/0x70 printaddressdescription.constprop.0+0x27/0x320 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] printreport+0x3e/0x70 kasanreport+0xab/0xe0 ? rtsxusbmspollcard+0x159/0x200 [rtsxusbms] rtsxusbmspollcard+0x159/0x200 [rtsxusbms] ? pfxrtsxusbmspollcard+0x10/0x10 [rtsxusbms] ? _pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 processonework+0x357/0x660 workerthread+0x390/0x4c0 ? _pfxworkerthread+0x10/0x10 kthread+0x190/0x1d0 ? _pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 161446: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 _kasankmalloc+0x7b/0x90 _kmallocnoprof+0x1a7/0x470 memstickallochost+0x1f/0xe0 [memstick] rtsxusbmsdrvprobe+0x47/0x320 [rtsxusbms] platformprobe+0x60/0xe0 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 _driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 _deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 _deviceattach+0x13a/0x2b0 busprobedevice+0xbd/0xd0 deviceadd+0x4a5/0x760 platformdeviceadd+0x189/0x370 mfdadddevice+0x587/0x5e0 mfdadddevices+0xb1/0x130 rtsxusbprobe+0x28e/0x2e0 [rtsxusb] usbprobeinterface+0x15c/0x460 calldriverprobe+0x35/0x120 reallyprobe+0x123/0x410 _driverprobedevice+0xc7/0x1e0 driverprobedevice+0x49/0xf0 _deviceattachdriver+0xc6/0x160 busforeachdrv+0xe4/0x160 _deviceattach+0x13a/0x2b0 rebindmarkedinterfaces.isra.0+0xcc/0x110 usbresetdevice+0x352/0x410 usbdevdoioctl+0xe5c/0x1860 usbdevioctl+0xa/0x20 _x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

Freed by task 161506: kasansavestack+0x20/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x36/0x60 _kasanslabfree+0x34/0x50 kfree+0x1fd/0x3b0 devicerelease+0x56/0xf0 kobjectcleanup+0x73/0x1c0 rtsxusbmsdrvremove+0x13d/0x220 [rtsxusbms] platformremove+0x2f/0x50 devicereleasedriverinternal+0x24b/0x2e0 busremovedevice+0x124/0x1d0 devicedel+0x239/0x530 platformdevicedel.part.0+0x19/0xe0 platformdeviceunregister+0x1c/0x40 mfdremovedevicesfn+0x167/0x170 deviceforeachchildreverse+0xc9/0x130 mfdremovedevices+0x6e/0xa0 rtsxusbdisconnect+0x2e/0xd0 [rtsxusb] usbunbindinterface+0xf3/0x3f0 devicereleasedriverinternal+0x24b/0x2e0 procdisconnectclaim+0x13d/0x220 usbdevdoioctl+0xb5e/0x1860 usbdevioctl+0xa/0x20 _x64sysioctl+0xc5/0xf0 dosyscall64+0x59/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 _queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 _runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handlesoftirqs+0xf9/0x360 _irqexitrcu+0x114/0x130 sysvecapictimerinterrupt+0x72/0x90 asmsysvecapictimer_interrupt+0x16/0x20

Second to last potentially related work creation: kasansavestack+0x20/0x40 kasanrecordauxstack+0x85/0x90 insertwork+0x29/0x100 _queuework+0x34a/0x540 calltimerfn+0x2a/0x160 expiretimers+0x5f/0x1f0 _runtimerbase.part.0+0x1b6/0x1e0 runtimersoftirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)

In the Linux kernel, the following vulnerability has been resolved:

nfsd: don't ignore the return code of svcprocregister()

Currently, nfsdprocstatinit() ignores the return value of svcproc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.

Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.

svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.(CVE-2025-22026)

In the Linux kernel, the following vulnerability has been resolved:

vhost-scsi: Fix handling of multiple calls to vhostscsiset_endpoint

If vhostscsisetendpoint is called multiple times without a vhostscsiclearendpoint between them, we can hit multiple bugs found by Haoran Zhang:

1. Use-after-free when no tpgs are found:

This fixes a use after free that occurs when vhostscsisetendpoint is called more than once and calls after the first call do not find any tpgs to add to the vstpg. When vhostscsisetendpoint first finds tpgs to add to the vstpg array match=true, so we will do:

vhostvqsetbackend(vq, vstpg); ...

kfree(vs->vstpg); vs->vstpg = vs_tpg;

If vhostscsisetendpoint is called again and no tpgs are found match=false so we skip the vhostvqsetbackend call leaving the pointer to the vs_tpg we then free via:

kfree(vs->vstpg); vs->vstpg = vs_tpg;

If a scsi request is then sent we do:

vhostscsihandlevq -> vhostscsigetreq -> vhostvqget_backend

which sees the vs_tpg we just did a kfree on.

2. Tpg dir removal hang:

This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.

The problem is that if vhostscsisetendpoint detects a tpg is already in the vs->vstpg array or if the tpg has been removed so targetdependitem fails, the undepend goto handler will do targetundependitem on all tpgs in the vstpg array dropping their refcount to 0. At this time vstpg contains both the tpgs we have added in the current vhostscsisetendpoint call as well as tpgs we added in previous calls which are also in vs->vstpg.

Later, when vhostscsiclearendpoint runs it will do targetundependitem on all the tpgs in the vs->vstpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.

3. Tpg leak:

This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhostscsiset_endpoint is called multiple times but with different target names.

The bug occurs if a user has called VHOSTSCSISETENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOSTSCSISETENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vstpg array. Later when we do vhostscsiclearendpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vstpg. We will then return from the function without doing targetundepend_item on the tpgs.

Because of all these bugs, it looks like being able to call vhostscsisetendpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhostscsisetendpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhostscsiclear_endpoint first.(CVE-2025-22083)

In the Linux kernel, the following vulnerability has been resolved:

net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105tabledelete_entry()

There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds.

The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.(CVE-2025-22107)

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: update channel list in reg notifier instead reg worker

Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue regwork. 2. cfg80211 handles new channel list during regwork. 3. update cfg80211's handled channel list to firmware by ath11kregupdatechanlist().

But ath11k will immediately execute step 3 after regwork is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11kregupdatechanlist Call Trace: ath11kregupdatechanlist+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11kregdupdate+0x1cf/0x350 [ath11k] ath11kregdupdatework+0x14/0x20 [ath11k] processonework+0xe35/0x14c0

Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211REGDOMSETBYDRIVER is set, cfg80211 will notify ath11k after step 2 is done.

So enable the flag NL80211REGDOMSETBYDRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3.

[1] https://patchwork.kernel.org/project/linux-wireless/patch/(CVE-2025-23133)

In the Linux kernel, the following vulnerability has been resolved:

i3c: Add NULL pointer check in i3cmasterqueue_ibi()

The I3C master driver may receive an IBI from a target device that has not been probed yet. In such cases, the master calls i3c_master_queue_ibi() to queue an IBI work task, leading to "Unable to handle kernel read from unreadable memory" and resulting in a kernel panic.

Typical IBI handling flow: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls i3c_device_request_ibi() to enable IBI and assigns dev->ibi = ibi. 3. The I3C master receives an IBI from the target device and calls i3c_master_queue_ibi() to queue the target device driver’s IBI handler task.

However, since target device events are asynchronous to the I3C probe sequence, step 3 may occur before step 2, causing dev->ibi to be NULL, leading to a kernel panic.

Add a NULL pointer check in i3c_master_queue_ibi() to prevent accessing an uninitialized dev->ibi, ensuring stability.(CVE-2025-23147)

In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi: add a check to handle OOB in sfr region

sfr->buf_size is in shared memory and can be modified by malicious user. OOB write is possible when the size is made higher than actual sfr data buffer. Cap the size to allocated size for such cases.(CVE-2025-23159)

In the Linux kernel, the following vulnerability has been resolved:

ata: patapxa: Fix potential NULL pointer dereference in pxaata_probe()

devmioremap() returns NULL on error. Currently, pxaata_probe() does not check for this case, which can result in a NULL pointer dereference.

Add NULL check after devm_ioremap() to prevent this issue.(CVE-2025-37758)

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in _smb2leasebreaknoti()

Move tcptransport free to ksmbdconnfree. If ksmbd connection is referenced when ksmbd server thread terminates, It will not be freed, but conn->tcptransport is freed. _smb2leasebreaknoti can be performed asynchronously when the connection is disconnected. _smb2leasebreaknoti calls ksmbdconnwrite, which can cause use-after-free when conn->ksmbd_transport is already freed.(CVE-2025-37777)

In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue

When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash.

Add flag 'ioadminreset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.(CVE-2025-37861)

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in session logoff

The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2sesssetup function which makes use of sess->user.(CVE-2025-37899)

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: displayport: Fix NULL pointer access

This patch ensures that the UCSI driver waits for all pending tasks in the ucsidisplayportwork workqueue to finish executing before proceeding with the partner removal.(CVE-2025-37994)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: fix region locking in hash types

Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahashbucketstart(), ahashbucketend() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.(CVE-2025-37997)

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma: Add missing locking

Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled:

[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udmastart.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [ 4.144867] Hardware name: pp-v12 (DT) [ 4.148648] Workqueue: events udmachecktxcompletion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udmastart.isra.0+0x34/0x238 [ 4.165227] lr : udmastart.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udmastart.isra.0+0x34/0x238 [ 4.251509] udmachecktxcompletion+0xd0/0xdc [ 4.256076] processonework+0x244/0x3fc [ 4.260129] processscheduledworks+0x6c/0x74 [ 4.264610] workerthread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] retfromfork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [<ffffffc080a27c7c>] _rawspinunlockirq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [<ffffffc080a1c154>] el1dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [<ffffffc080037e68>] handlesoftirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [<ffffffc080010170>] _dosoftirq+0x1c/0x28 [ 4.311559] ---[ end trace 0000000000000000 ]---

This commit adds the missing locking.(CVE-2025-38005)

In the Linux kernel, the following vulnerability has been resolved:

_legitimizemnt(): check for MNTSYNCUMOUNT should be under mount_lock

... or we risk stealing final mntput from sync umount - raising mntcount after umount(2) has verified that victim is not busy, but before it has set MNTSYNCUMOUNT; in that case _legitimizemnt() doesn't see that it's safe to quietly undo mntcount increment and leaves dropping the reference to caller, where it'll be a full-blown mntput().

Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.(CVE-2025-38058)

In the Linux kernel, the following vulnerability has been resolved:

x86/mm: Check return value from memblockphysalloc_range()

At least with CONFIGPHYSICALSTART=0x100000, if there is < 4 MiB of contiguous free memory available at this point, the kernel will crash and burn because memblockphysallocrange() returns 0 on failure, which leads memblockphys_free() to throw the first 4 MiB of physical memory to the wolves.

At a minimum it should fail gracefully with a meaningful diagnostic, but in fact everything seems to work fine without the weird reserve allocation.(CVE-2025-38071)

In the Linux kernel, the following vulnerability has been resolved:

nfsd: Initialize ssc before laundromat_work to prevent NULL dereference

In nfs4statestartnet(), laundromatwork may access nfsdssc through nfs4laundromat -> nfsd4sscexpireumount. If nfsdssc isn't initialized, this can cause NULL pointer dereference.

Normally the delayed start of laundromatwork allows sufficient time for nfsdssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4statestartnet -> nfsd4endgrace -> nfsd4recordgracedone -> nfsd4cldgracedone -> cldpipeupcall -> _cldpipeupcall -> waitforcompletion path), the delayed work may start before nfsd_ssc initialization finishes.

Fix this by moving nfsdssc initialization before starting laundromatwork.(CVE-2025-38231)

In the Linux kernel, the following vulnerability has been resolved:

nbd: fix uaf in nbdgenlconnect() error path

There is a use-after-free issue in nbd:

block nbd6: Receive control failed (result -104)

block nbd6: shutting down sockets

BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022 Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67

CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: nbd6-recv recvwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0xef/0x1a0 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicdec include/linux/atomic/atomic-instrumented.h:592 [inline] recvwork+0x694/0xa80 drivers/block/nbd.c:1022 processonework+0x9cc/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>

nbdgenlconnect() does not properly stop the device on certain error paths after nbdstartdevice() has been called. This causes the error path to put nbd->config while recvwork continue to use the config after putting it, leading to use-after-free in recvwork.

This patch moves nbdstartdevice() after the backend file creation.(CVE-2025-38443)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: schqfq: Fix race condition on qfqaggregate

A race condition can occur when 'agg' is modified in qfqchangeagg (called during qfqenqueue) while other threads access it concurrently. For example, qfqdumpclass may trigger a NULL dereference, and qfqdelete_class may cause a use-after-free.

This patch addresses the issue by:

1. Moved qfqdestroyclass into the critical section.

2. Added schtreelock protection to qfqdumpclass and qfqdumpclass_stats.(CVE-2025-38477)

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: limit repeated connections from clients with the same IP

Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP.(CVE-2025-38501)

In the Linux kernel, the following vulnerability has been resolved:

sunrpc: fix handling of server side tls alerts

Scott Mayhew discovered a security exploit in NFS over TLS in tlsalertrecv() due to its assumption it can read data from the msg iterator's kvec..

kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer.

This patch proposes to rework how control messages are setup and used by sock_recvmsg().

If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tlsalertrecv.(CVE-2025-38566)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: Fix backlog accounting in qdiscdequeueinternal

This issue applies for the following qdiscs: hhf, fq, fqcodel, and fqpie, and occurs in their change handlers when adjusting to the new limit. The problem is the following in the values passed to the subsequent qdisctreereduce_backlog call given a tbf parent:

When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gsoskb. Their peek handlers are qdiscpeekdequeued, which accounts for both qlen and backlog. However, in the case of qdiscdequeueinternal, ONLY qlen is accounted for when pulling from gsoskb. This means that these qdiscs are missing a qdiscqstatsbacklog_dec when dropping packets to satisfy the new limit in their change handlers.

One can observe this issue with the following (with tc patched to support a limit of 0):

export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo

The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdiscpurgequeue triggers qdisctreereduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0).

To fix this issue, the codepath for all clients of qdiscdequeueinternal has been simplified: codel, pie, hhf, fq, fqpie, and fqcodel. qdiscdequeueinternal handles the backlog adjustments for all cases that do not directly use the dequeue handler.

The old fqcodelchange limit adjustment loop accumulated the arguments to the subsequent qdisctreereducebacklog call through the cstats field. However, this is confusing and error prone as fqcodeldequeue could also potentially mutate this field (which qdiscdequeueinternal calls in the non gsoskb case), so we have unified the code here with other qdiscs.(CVE-2025-39677)

In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix memory corruption when FW resources change during ifdown

bnxtsetdfltrings() assumes that it is always called before any TC has been created. So it doesn't take bp->numtc into account and assumes that it is always 0 or 1.

In the FW resource or capability change scenario, the FW will return flags in bnxthwrmifchange() that will cause the driver to reinitialize and call bnxtcancelreservations(). This will lead to bnxtinitdfltringmode() calling bnxtsetdfltrings() and bp->numtc may be greater than 1. This will cause bp->txring[] to be sized too small and cause memory corruption in bnxtalloccp_rings().

Fix it by properly scaling the TX rings by bp->numtc in the code paths mentioned above. Add 2 helper functions to determine bp->txnrrings and bp->txnrringsper_tc.(CVE-2025-39810)

In the Linux kernel, the following vulnerability has been resolved:

efivarfs: Fix slab-out-of-bounds in efivarfsdcompare

Observed on kernel 6.6 (present on master as well):

BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasancheckrange+0xe8/0x190 _asanloadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfsdcompare+0x68/0xd8 _dlookuprcuopcompare+0x178/0x218 _dlookuprcu+0x1f8/0x228 dallocparallel+0x150/0x648 lookupopen.isra.0+0x5f0/0x8d0 openlastlookups+0x264/0x828 pathopenat+0x130/0x3f8 dofilpopen+0x114/0x248 dosysopenat2+0x340/0x3c0 _arm64sys_openat+0x120/0x1a0

If dentry->dname.len < EFIVARIABLEGUIDLEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename:

T1 T2 lookupopen ->lookup simplelookup d_add // invalid dentry is added to hash list

        lookup_open
         d_alloc_parallel
          __d_lookup_rcu
           __d_lookup_rcu_op_compare
            hlist_bl_for_each_entry_rcu
            // invalid dentry can be retrieved
             ->d_compare
              efivarfs_d_compare
              // oob

Fix it by checking 'guid' before cmp.(CVE-2025-39817)

In the Linux kernel, the following vulnerability has been resolved:

fs: writeback: fix use-after-free in _markinode_dirty()

An use-after-free issue occurred when _markinodedirty() get the bdiwriteback that was in the progress of switching.

CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _markinodedirty+0x124/0x418 lr : _markinodedirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: _markinodedirty+0x124/0x418 genericupdatetime+0x4c/0x60 filemodified+0xcc/0xd0 ext4bufferedwriteiter+0x58/0x124 ext4filewriteiter+0x54/0x704 vfswrite+0x1c0/0x308 ksyswrite+0x74/0x10c _arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x114 el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x40/0xe4 el0t64synchandler+0x120/0x12c el0t64sync+0x194/0x198

Root cause is:

systemd-random-seed kworker

_markinodedirty inodeswitchwbsworkfn

spinlock(&inode->ilock); inodeattachwb lockedinodetowbandlocklist get inode->iwb spinunlock(&inode->ilock); spinlock(&wb->listlock) spinlock(&inode->ilock) inodeiolistmovelocked spinunlock(&wb->listlock) spinunlock(&inode->ilock) spinlock(&oldwb->listlock) inodedoswitchwbs spinlock(&inode->ilock) inode->iwb = newwb spinunlock(&inode->ilock) spinunlock(&oldwb->listlock) wbputmany(oldwb, nrswitched) cgwbrelease old wb released wbwakeup_delayed() accesses wb, then trigger the use-after-free issue

Fix this race condition by holding inode spinlock until wbwakeupdelayed() finished.(CVE-2025-39866)

In the Linux kernel, the following vulnerability has been resolved:

i40e: fix IRQ freeing in i40evsirequestirqmsix error path

If requestirq() in i40evsirequestirqmsix() fails in an iteration later than the first, the error path wants to free the IRQs requested so far. However, it uses the wrong devid argument for free_irq(), so it does not free the IRQs correctly and instead triggers the warning:

Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 freeirq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:freeirq+0x192/0x2c0 [...] Call Trace: <TASK> freeirq+0x32/0x70 i40evsirequestirqmsix.cold+0x63/0x8b [i40e] i40evsirequestirq+0x79/0x80 [i40e] i40evsiopen+0x21f/0x2f0 [i40e] i40eopen+0x63/0x130 [i40e] devopen+0xfc/0x210 _devchangeflags+0x1fc/0x240 netifchangeflags+0x27/0x70 dosetlink.isra.0+0x341/0xc70 rtnlnewlink+0x468/0x860 rtnetlinkrcvmsg+0x375/0x450 netlinkrcvskb+0x5c/0x110 netlinkunicast+0x288/0x3c0 netlinksendmsg+0x20d/0x430 _syssendmsg+0x3a2/0x3d0 _syssendmsg+0x99/0xe0 _syssendmsg+0x8a/0xf0 dosyscall64+0x82/0x2c0 entrySYSCALL64afterhwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---

Use the same devid for freeirq() as for request_irq().

I tested this with inserting code to fail intentionally.(CVE-2025-39911)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Harden uplink netdev access against device unbind

The function mlx5uplinknetdevget() gets the uplink netdevice pointer from mdev->mlx5eres.uplinknetdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5core.eth driver. This results in a NULL pointer, causing a kernel panic.

BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5evportrepload+0x22a/0x270 [mlx5core] Call Trace: <TASK> mlx5eswoffloadsrepload+0x68/0xe0 [mlx5core] eswoffloadsenable+0x593/0x910 [mlx5core] mlx5eswitchenablelocked+0x341/0x420 [mlx5core] mlx5devlinkeswitchmodeset+0x17e/0x3a0 [mlx5core] devlinknleswitchsetdoit+0x60/0xd0 genlfamilyrcvmsgdoit+0xe0/0x130 genlrcvmsg+0x183/0x290 netlinkrcvskb+0x4b/0xf0 genlrcv+0x24/0x40 netlinkunicast+0x255/0x380 netlinksendmsg+0x1f3/0x420 _socksendmsg+0x38/0x60 _syssendto+0x119/0x180 dosyscall64+0x53/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53

Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.(CVE-2025-39947)

In the Linux kernel, the following vulnerability has been resolved:

media: b2c2: Fix use-after-free causing by irqcheckwork in flexcoppciremove

The original code uses canceldelayedwork() in flexcoppciremove(), which does not guarantee that the delayed work item irqcheckwork has fully completed if it was already running. This leads to use-after-free scenarios where flexcoppciremove() may free the flexcopdevice while irqcheck_work is still active and attempts to dereference the device.

A typical race condition is illustrated below:

CPU 0 (remove) | CPU 1 (delayed work callback) flexcoppciremove() | flexcoppciirqcheckwork() canceldelayedwork() | flexcopdevicekfree(fcpci->fcdev) | | fc = fcpci->fcdev; // UAF

This is confirmed by a KASAN report:

================================================================== BUG: KASAN: slab-use-after-free in runtimerbase.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: <IRQ> dumpstacklvl+0x55/0x70 printreport+0xcf/0x610 ? _runtimerbase.part.0+0x7d7/0x8c0 kasanreport+0xb8/0xf0 ? _runtimerbase.part.0+0x7d7/0x8c0 _runtimerbase.part.0+0x7d7/0x8c0 ? _pfxruntimerbase.part.0+0x10/0x10 ? _pfxreadtsc+0x10/0x10 ? ktimeget+0x60/0x140 ? lapicnextevent+0x11/0x20 ? clockeventsprogramevent+0x1d4/0x2a0 runtimersoftirq+0xd1/0x190 handlesoftirqs+0x16a/0x550 irqexitrcu+0xaf/0xe0 sysvecapictimer_interrupt+0x70/0x80 </IRQ> ...

Allocated by task 1: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0x7f/0x90 _kmallocnoprof+0x1be/0x460 flexcopdevicekmalloc+0x54/0xe0 flexcoppciprobe+0x1f/0x9d0 localpciprobe+0xdc/0x190 pcideviceprobe+0x2fe/0x470 reallyprobe+0x1ca/0x5c0 _driverprobedevice+0x248/0x310 driverprobedevice+0x44/0x120 _driverattach+0xd2/0x310 busforeachdev+0xed/0x170 busadddriver+0x208/0x500 driverregister+0x132/0x460 dooneinitcall+0x89/0x300 kernelinitfreeable+0x40d/0x720 kernelinit+0x1a/0x150 retfromfork+0x10c/0x1a0 retfromforkasm+0x1a/0x30

Freed by task 135: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3a/0x60 _kasanslabfree+0x3f/0x50 kfree+0x137/0x370 flexcopdevicekfree+0x32/0x50 pcideviceremove+0xa6/0x1d0 devicereleasedriverinternal+0xf8/0x210 pcistopbusdevice+0x105/0x150 pcistopandremovebusdevicelocked+0x15/0x30 removestore+0xcc/0xe0 kernfsfopwriteiter+0x2c3/0x440 vfswrite+0x871/0xd70 ksyswrite+0xee/0x1c0 dosyscall64+0xac/0x280 entrySYSCALL64afterhwframe+0x77/0x7f ...

Replace canceldelayedwork() with canceldelayedwork_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated.

This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcoppciirqcheckwork() function to increase the likelihood of triggering the bug.(CVE-2025-39996)

In the Linux kernel, the following vulnerability has been resolved:

media: uvcvideo: Mark invalid entities with id UVCINVALIDENTITY_ID

Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.

Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,

If we add a new entity with id 0 or a duplicated ID, it will be marked as UVCINVALIDENTITY_ID.

In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require entities to have a non-zero unique ID"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time.

This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.

In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.

Here is a sample stack trace for one of those cases.

[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummyhcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 mediacreatepadlink+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usbhubwq hubevent [ 21.045100] RIP: 0010:mediacreatepadlink+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? _warn+0xc4/0x210 [ 21.051861] ? mediacreatepadlink+0x2c4/0x2e0 [ 21.052252] ? reportbug+0x11b/0x1a0 [ 21.052540] ? tracehardirqson+0x31/0x40 [ 21.052901] ? handlebug+0x3d/0x70 [ 21.053197] ? excinvalidop+0x1a/0x50 [ 21.053511] ? asmexcinvalidop+0x1a/0x20 [ 21.053924] ? mediacreatepadlink+0x91/0x2e0 [ 21.054364] ? mediacreatepadlink+0x2c4/0x2e0 [ 21.054834] ? mediacreatepadlink+0x91/0x2e0 [ 21.055131] ? rawspinunlock+0x1e/0x40 [ 21.055441] ? _v4l2deviceregistersubdev+0x202/0x210 [ 21.055837] uvcmcregisterentities+0x358/0x400 [ 21.056144] uvcregisterchains+0x1 ---truncated---(CVE-2025-40016)