The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

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:

usb: cdns3: Fix deadlock when using NCM gadget

The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").

Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using "iperf --bidir" over NCM ethernet link.

The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler.(CVE-2025-37812)

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

jbd2: remove wrong sb->s_sequence check

Journal emptiness is not determined by sb->ssequence == 0 but rather by sb->sstart == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON.(CVE-2025-37839)

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

ovl: don't allow datadir only

In theory overlayfs could support upper layer directly referring to a data layer, but there's no current use case for this.

Originally, when data-only layers were introduced, this wasn't allowed, only introduced by the "datadir+" feature, but without actually handling this case, resulting in an Oops.

Fix by disallowing datadir without lowerdir.(CVE-2025-37863)

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

ALSA: ump: Fix buffer overflow at UMP SysEx message conversion

The conversion function from MIDI 1.0 to UMP packet contains an internal buffer to keep the incoming MIDI bytes, and its size is 4, as it was supposed to be the max size for a MIDI1 UMP packet data. However, the implementation overlooked that SysEx is handled in a different format, and it can be up to 6 bytes, as found in doconvertto_ump(). It leads eventually to a buffer overflow, and may corrupt the memory when a longer SysEx message is received.

The fix is simply to extend the buffer size to 6 to fit with the SysEx UMP message.(CVE-2025-37891)

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

sched/rt: Fix race in pushrttask

Overview

When a CPU chooses to call pushrttask and picks a task to push to another CPU's runqueue then it will call findlocklowestrq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (onrq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list.

Crashes

This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself.

Some of the crashes: -> kernel BUG at kernel/sched/rt.c:1616! BUGON(idx >= MAXRTPRIO) Call Trace: ? _diebody+0x1a/0x60 ? die+0x2a/0x50 ? dotrap+0x85/0x100 ? picknexttaskrt+0x6e/0x1d0 ? doerrortrap+0x64/0xa0 ? picknexttaskrt+0x6e/0x1d0 ? excinvalidop+0x4c/0x60 ? picknexttaskrt+0x6e/0x1d0 ? asmexcinvalidop+0x12/0x20 ? picknexttaskrt+0x6e/0x1d0 _schedule+0x5cb/0x790 ? updatetstimestats+0x55/0x70 scheduleidle+0x1e/0x40 doidle+0x15e/0x200 cpustartupentry+0x19/0x20 startsecondary+0x117/0x160 secondarystartup64noverify+0xb0/0xbb

-> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? _diebody+0x1a/0x60 ? nocontext+0x183/0x350 ? _warn+0x8a/0xe0 ? excpagefault+0x3d6/0x520 ? asmexcpagefault+0x1e/0x30 ? picknexttaskrt+0xb5/0x1d0 ? picknexttaskrt+0x8c/0x1d0 _schedule+0x583/0x7e0 ? updatetstimestats+0x55/0x70 scheduleidle+0x1e/0x40 doidle+0x15e/0x200 cpustartupentry+0x19/0x20 startsecondary+0x117/0x160 secondarystartup64noverify+0xb0/0xbb

-> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUGON(rq->cpu != taskcpu(p))

-> kernel BUG at kernel/sched/rt.c:1055! BUGON(!rq->nrrunning) Call Trace: ? _diebody+0x1a/0x60 ? die+0x2a/0x50 ? dotrap+0x85/0x100 ? dequeuetoprtrq+0xa2/0xb0 ? doerrortrap+0x64/0xa0 ? dequeuetoprtrq+0xa2/0xb0 ? excinvalidop+0x4c/0x60 ? dequeuetoprtrq+0xa2/0xb0 ? asmexcinvalidop+0x12/0x20 ? dequeuetoprtrq+0xa2/0xb0 dequeuertentity+0x1f/0x70 dequeuetaskrt+0x2d/0x70 _schedule+0x1a8/0x7e0 ? blkfinishplug+0x25/0x40 schedule+0x3c/0xb0 futexwaitqueueme+0xb6/0x120 futexwait+0xd9/0x240 dofutex+0x344/0xa90 ? getmmexefile+0x30/0x60 ? auditexecompare+0x58/0x70 ? auditfilterrules.constprop.26+0x65e/0x1220 _x64sysfutex+0x148/0x1f0 dosyscall64+0x30/0x80 entrySYSCALL64afterhwframe+0x62/0xc7

-> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? _diebody+0x1a/0x60 ? nocontext+0x183/0x350 ? spuriouskernelfault+0x171/0x1c0 ? excpagefault+0x3b6/0x520 ? plistchecklist+0x15/0x40 ? plistchecklist+0x2e/0x40 ? asmexcpagefault+0x1e/0x30 ? condresched+0x15/0x30 ? futexwaitqueueme+0xc8/0x120 ? futexwait+0xd9/0x240 ? trytowakeup+0x1b8/0x490 ? futexwake+0x78/0x160 ? dofutex+0xcd/0xa90 ? plistchecklist+0x15/0x40 ? plistchecklist+0x2e/0x40 ? plistdel+0x6a/0xd0 ? plistchecklist+0x15/0x40 ? plistchecklist+0x2e/0x40 ? dequeuepushabletask+0x20/0x70 ? _schedule+0x382/0x7e0 ? asmsysvecreschedulei ---truncated---(CVE-2025-38234)

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

eventpoll: don't decrement ep refcount while still holding the ep mutex

Jann Horn points out that epoll is decrementing the ep refcount and then doing a

mutex_unlock(&ep->mtx);

afterwards. That's very wrong, because it can lead to a use-after-free.

That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "ep_free(ep)" until after it has unlocked the mutex.

But it's wrong for the much subtler "next to last" case when somebody else may also be dropping their reference and free the ep while we're still using the mutex.

Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion.

A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up.

See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics:

"mutex_unlock() may access the mutex structure even after it has
 internally released the lock already - so it's not safe for
 another context to acquire the mutex and assume that the
 mutex_unlock() context is not using the structure anymore"

So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops their reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it.

Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole point of refcounts: unlike mutexes, they are inherently about object lifetimes).(CVE-2025-38349)

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

drm/hisilicon/hibmc: fix irq_request()'s irq name variable is local

The local variable is passed in requestirq (), and there will be use after free problem, which will make requestirq failed. Using the global irq name instead of it to fix.(CVE-2025-39785)