OESA-2025-2556

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcpwritetimerhandler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dumpstacklvl+0x68/0xa0 printaddressdescription.constprop.0+0x2c/0x3d0 printreport+0xb4/0x270 kasanreport+0xbd/0xf0 tcpwritetimerhandler+0x156/0x3e0 tcpwritetimer+0x66/0x170 calltimerfn+0xfb/0x1d0 _runtimers+0x3f8/0x480 runtimersoftirq+0x9b/0x100 handlesoftirqs+0x153/0x390 _irqexitrcu+0x103/0x120 irqexitrcu+0xe/0x20 sysvecapictimerinterrupt+0x76/0x90 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20RIP: 0010:defaultidle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 defaultidlecall+0x6b/0xa0 cpuidleidlecall+0x1af/0x1f0 doidle+0xbc/0x130 cpustartupentry+0x33/0x40 restinit+0x11f/0x210 startkernel+0x39a/0x420 x8664startreservations+0x18/0x30 x8664startkernel+0x97/0xa0 commonstartup64+0x13e/0x141 </TASK>Allocated by task 595: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 _kasanslaballoc+0x87/0x90 kmemcacheallocnoprof+0x12b/0x3f0 copynetns+0x94/0x380 createnewnamespaces+0x24c/0x500 unsharensproxynamespaces+0x75/0xf0 ksysunshare+0x24e/0x4f0 _x64sysunshare+0x1f/0x30 dosyscall64+0x70/0x180 entrySYSCALL64afterhwframe+0x76/0x7eFreed by task 100: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x54/0x70 kmemcachefree+0x156/0x5d0 cleanupnet+0x5d3/0x670 processonework+0x776/0xa90 workerthread+0x2e2/0x560 kthread+0x1a8/0x1f0 retfromfork+0x34/0x60 retfromforkasm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,norootsquash *:/mnt/nfsshareip netns add netns1ip link add name veth1peer type veth peer veth1ifconfig veth1peer 11.11.0.254 upip link set veth1 netns netns1ip netns exec netns1 ifconfig veth1 11.11.0.1ip netns exec netns1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROYCLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns1ip netns del netns1The reason here is that the tcp socket in netns1 (nfs side) has beenshutdown and closed (done in xsdestroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)

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

x86/amdnb: Use rdmsrsafe() in amdgetmmconfig_range()

Xen doesn't offer MSRFAM10HMMIOCONFBASE to all guests. This results in the following warning:

unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xendoreadmsr+0x7f/0xa0) Call Trace: xenreadmsr+0x1e/0x30 amdgetmmconfigrange+0x2b/0x80 quirkamdmmconfigarea+0x28/0x100 pnpfixupdevice+0x39/0x50 _pnpadddevice+0xf/0x150 pnpadddevice+0x3d/0x100 pnpacpiadddevicehandler+0x1f9/0x280 acpinsgetdevicecallback+0x104/0x1c0 acpinswalknamespace+0x1d0/0x260 acpigetdevices+0x8a/0xb0 pnpacpiinit+0x50/0x80 dooneinitcall+0x46/0x2e0 kernelinitfreeable+0x1da/0x2f0 kernelinit+0x16/0x1b0 retfromfork+0x30/0x50 retfromfork_asm+0x1b/0x30

based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.

This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.(CVE-2025-21913)

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

pds_core: Prevent possible adminq overflow/stuck condition

The pdscore's adminq is protected by the adminqlock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion.

On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW.

As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.(CVE-2025-37987)

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

module: ensure that kobject_put() is safe for module type kobjects

In 'lookuporcreatemodulekobject()', an internal kobject is created using 'modulektype'. So call to 'kobjectput()' on error handling path causes an attempt to use an uninitialized completion pointer in 'modulekobjectrelease()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.(CVE-2025-37995)

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

regulator: core: fix NULL dereference on unbind due to stale coupling data

Failing to reset couplingdesc.ncoupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind.

This can happen during runtime PM or other regulator operations that rely on coupling metadata.

For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulatorlockrecursive() due to stale coupling state.

Ensure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)

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

drm/nouveau/nvif: Fix potential memory leak in nvifvmmctor().

When the nvifvmmtype is invalid, we will return error directly without freeing the args in nvifvmmctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)

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

serial: 8250: fix panic due to PSLVERR

When the PSLVERRRESPEN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled.

In serial8250dostartup(), calling serialportout(port, UARTLCR, UARTLCRWLEN8) triggers dw8250checklcr(), which invokes dw8250forceidle() and serial8250clearandreinitfifos(). The latter function enables the FIFO via serialout(p, UARTFCR, p->fcr). Execution proceeds to the serialportin(port, UARTRX). This satisfies the PSLVERR trigger condition.

When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UARTLCRSPAR) == (lcr & ~UARTLCRSPAR) in dw8250checklcr(), causing it to enter dw8250forceidle().

Put serialportout(port, UARTLCR, UARTLCR_WLEN8) under the port->lock to fix this issue.

Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250serialin32+0x1e/0x4a [ 0.442351] ra : serial8250dostartup+0x2c8/0x88e ... [ 0.442416] consoleonrootfs+0x26/0x70(CVE-2025-39724)

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

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

A malicious HID device can trigger a slab out-of-bounds during mtreportfixup() by passing in report descriptor smaller than 607 bytes. mtreportfixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it.

Below is the KASAN splat after the out of bounds access happens:

[ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mtreportfixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dumpstacklvl+0x5f/0x80 [ 13.673297] printreport+0xd1/0x660 [ 13.673297] kasanreport+0xe5/0x120 [ 13.673297] _asanreportload1noabort+0x18/0x20 [ 13.673297] mtreportfixup+0x103/0x110 [ 13.673297] hidopenreport+0x1ef/0x810 [ 13.673297] mtprobe+0x422/0x960 [ 13.673297] hiddeviceprobe+0x2e2/0x6f0 [ 13.673297] reallyprobe+0x1c6/0x6b0 [ 13.673297] _driverprobedevice+0x24f/0x310 [ 13.673297] driverprobedevice+0x4e/0x220 [ 13.673297] _deviceattachdriver+0x169/0x320 [ 13.673297] busforeachdrv+0x11d/0x1b0 [ 13.673297] _deviceattach+0x1b8/0x3e0 [ 13.673297] deviceinitialprobe+0x12/0x20 [ 13.673297] busprobedevice+0x13d/0x180 [ 13.673297] deviceadd+0xe3a/0x1670 [ 13.673297] hidadddevice+0x31d/0xa40 ...

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)

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

fbcon: fix integer overflow in fbcondoset_font

Fix integer overflow vulnerabilities in fbcondoset_font() where font size calculations could overflow when handling user-controlled font parameters.

The vulnerabilities occur when: 1. CALCFONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONTEXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.

Add explicit overflow checking using checkmuloverflow() and checkaddoverflow() kernel helpers to safety validate all size calculations before allocation.(CVE-2025-39967)

In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hcievent: Fix UAF in hciaclcreateconnsyncThis fixes the following UFA in hciaclcreateconnsync where aconnection still pending is command submission (conn->state == BTOPEN)maybe freed, also since this also can happen with the likes ofhcilecreateconnsync fix it as well:BUG: KASAN: slab-use-after-free in hciaclcreateconnsync+0x5ef/0x790 net/bluetooth/hcisync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hcicmdsyncworkCall Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x230 mm/kasan/report.c:480 kasanreport+0x118/0x150 mm/kasan/report.c:593 hciaclcreateconnsync+0x5ef/0x790 net/bluetooth/hcisync.c:6861 hcicmdsyncwork+0x210/0x3a0 net/bluetooth/hcisync.c:332 processonework kernel/workqueue.c:3238 [inline] processscheduledworks+0xae1/0x17b0 kernel/workqueue.c:3321 workerthread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry64.S:245 </TASK>Allocated by task 123736: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x93/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _kmalloccachenoprof+0x230/0x3d0 mm/slub.c:4359 kmallocnoprof include/linux/slab.h:905 [inline] kzallocnoprof include/linux/slab.h:1039 [inline] _hciconnadd+0x233/0x1b30 net/bluetooth/hciconn.c:939 hciconnaddunset net/bluetooth/hciconn.c:1051 [inline] hciconnectacl+0x16c/0x4e0 net/bluetooth/hciconn.c:1634 pairdevice+0x418/0xa70 net/bluetooth/mgmt.c:3556 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg+0x219/0x270 net/socket.c:727 sockwriteiter+0x258/0x330 net/socket.c:1131 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x54b/0xa90 fs/readwrite.c:686 ksyswrite+0x145/0x250 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7fFreed by task 103680: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x46/0x50 mm/kasan/generic.c:576 poisonslabobject mm/kasan/common.c:247 [inline] _kasanslabfree+0x62/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2381 [inline] slabfree mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 devicerelease+0x9c/0x1c0 kobjectcleanup lib/kobject.c:689 [inline] kobjectrelease lib/kobject.c:720 [inline] krefput include/linux/kref.h:65 [inline] kobjectput+0x22b/0x480 lib/kobject.c:737 hciconncleanup net/bluetooth/hciconn.c:175 [inline] hciconndel+0x8ff/0xcb0 net/bluetooth/hciconn.c:1173 hciconncompleteevt+0x3c7/0x1040 net/bluetooth/hcievent.c:3199 hcieventfunc net/bluetooth/hcievent.c:7477 [inline] hcieventpacket+0x7e0/0x1200 net/bluetooth/hcievent.c:7531 hcirxwork+0x46a/0xe80 net/bluetooth/hcicore.c:4070 processonework kernel/workqueue.c:3238 [inline] processscheduledworks+0xae1/0x17b0 kernel/workqueue.c:3321 workerthread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromfork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)

In the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imondisconnect() improperly releasing the usbdevice reference 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, usbputdev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usbdevice pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)

In the Linux kernel, a buffer overflow vulnerability exists in the targetlugpmembersshow function in targetcoreconfigfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LUGROUPNAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)

In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essivaeadcrypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)