OESA-2025-2632

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

SUNRPC: make sure cache entry active before cache_show

The function c_show was called with protection from RCU. This only ensures that cp will not be freed. Therefore, the reference count for cp can drop to zero, which will trigger a refcount use-after-free warning when cache_get is called. To resolve this issue, use cache_get_rcu to ensure that cp remains active.

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcountwarnsaturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarn_saturate+0xb1/0x120

Call Trace: <TASK> cshow+0x2fc/0x380 [sunrpc] seqreaditer+0x589/0x770 seqread+0x1e5/0x270 procregread+0xe1/0x140 vfsread+0x125/0x530 ksysread+0xc1/0x160 dosyscall64+0x5f/0x170 entrySYSCALL64afterhwframe+0x76/0x7e(CVE-2024-53174)

In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dmarraycursorendWhen dmbmreadlock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dmbmreadlock() should not operate onthis invalid dmblock pointer, or it will lead to undefined result.For example, the dmarraycursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indmarraycursorend(), then hitting the BUGON in dm-bufio cacheput().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 65536 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc $262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmappingroot=$(dd if=/dev/sdc bs=1c count=8 skip=192 2>/dev/null | hexdump -e 1/8 %u n )ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mappingroot+2056)) 2>/dev/null | hexdump -e 1/8 %u n )dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 65536 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc $262144 dmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 Kernel logs:(snip)device-mapper: array: arrayblockcheck failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: getablock faileddevice-mapper: cache metadata: dmarraycursornext for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the arraycursor/damaged test in dm-unit: dm-unit run /pdata/arraycursor/damaged --kernel-dir <KERNELDIR>(CVE-2024-57929)

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

mm/vmscan: fix hwpoisoned large folio handling in shrinkfoliolist

In shrinkfoliolist(), the hwpoisoned folio may be large folio, which can't be handled by unmappoisonedfolio(). For THP, trytounmapone() must be passed with TTUSPLITHUGEPMD to split huge PMD first and then retry. Without TTUSPLITHUGEPMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTUSPLITHUGEPMD, we will trigger a WARNONONCE due to the page isn't in swapcache.

Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again.

This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows:

cpu0 cpu1 shrinkfoliolist memoryfailure TestSetPageHWPoison unmappoisonedfolio --> trigger BUGON due to unmappoisonedfolio couldn't handle large folio

[(CVE-2025-39725)

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

i40e: add validation for ring_len param

The ring_len parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation.

To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)

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

media: rc: fix races with imon_disconnect()

Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in _createpipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465

CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xcd/0x134 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:317 [inline] printreport.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasanreport+0xb1/0x1e0 mm/kasan/report.c:495 _createpipe include/linux/usb.h:1945 [inline] sendpacket+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfdwrite+0x2d9/0x550 drivers/media/rc/imon.c:991 vfswrite+0x2d7/0xdd0 fs/readwrite.c:576 ksyswrite+0x127/0x250 fs/readwrite.c:631 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

The iMON driver improperly releases the usbdevice reference in imondisconnect without coordinating with active users of the device.

Specifically, the fields usbdevintf0 and usbdevintf1 are not protected by the users counter (ictx->users). During probe, imoninitintf0 or imoninitintf1 increments the usbdevice reference count depending on the interface. However, during disconnect, usbput_dev is called unconditionally, regardless of actual usage.

As a result, if vfdwrite or other operations are still in progress after disconnect, this can lead to a use-after-free of the usbdevice pointer.

Thread 1 vfdwrite Thread 2 imondisconnect ... if usbputdev(ictx->usbdevintf0) else usbputdev(ictx->usbdevintf1) ... while sendpacket if pipe = usbsndintpipe( ictx->usbdevintf0) UAF else pipe = usbsndctrlpipe( ictx->usbdev_intf0, 0) UAF

Guard access to usbdevintf0 and usbdevintf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in sendpacket(), vfdwrite(), lcdwrite() and displayopen() if the device is no longer present.

Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.

Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-39993)

In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamicevents interface on tracefs is compatible withkprobeevents and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)

There is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perfevents initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perfevents pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/tracekprobe.c at line 1308, the kprobeperffunc function attempts to access the call->perfevents pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)

In the Linux kernel, a vulnerability exists in the UDF filesystem's handling of Allocation Extent Descriptors. When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udfupdatetag() to call crcitut() on out-of-bounds memory and trigger a KASAN use-after-free read. This vulnerability was found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)

In the Linux kernel, an integer overflow vulnerability exists in the armspe component of the perf subsystem. The PERFIDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)