OESA-2025-2553

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net/tunnel: wait until all skuserdata reader finish before releasing the sock

There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlansock vs from skuserdata. Then in later vxlanecndecapsulate(), vxlangetskfamily() we will got NULL pointer dereference. e.g.

#0 [ffffa25ec6978a38] machinekexec at ffffffff8c669757 #1 [ffffa25ec6978a90] _crashkexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crashkexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oopsend at ffffffff8c627f2b #4 [ffffa25ec6978b80] pagefaultoops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] excpagefault at ffffffff8d109542 #6 [ffffa25ec6978c00] asmexcpagefault at ffffffff8d200b62 [exception RIP: vxlanecndecapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlanrcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udpqueuercvoneskb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udpunicastrcvskb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] _udp4librcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ipprotocoldeliverrcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] iplocaldeliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] _netifreceiveskbonecore at ffffffff8cecde9b #14 [ffffa25ec6978ec8] processbacklog at ffffffff8cece139 #15 [ffffa25ec6978f00] _napipoll at ffffffff8ceced1a #16 [ffffa25ec6978f28] netrxaction at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] _softirqentrytextstart at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3

Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh

Fix this by waiting for all skuserdata reader to finish before releasing the sock.(CVE-2022-50405)

In the Linux kernel, there is a vulnerability in the USB host controller interface (xHCI). When the xHC host is dying or being removed, endpoints are not properly cleaned up, remaining in the bandwidth list when freeing the virtual device. This causes a listdel corruption kernel crash when unbinding xhci-pci, as xhcimem_cleanup() later attempts to delete already freed endpoints from the bandwidth list. This vulnerability only affects hosts that use software bandwidth checking, which currently is only the xHC in Intel Panther Point PCH (Ivy Bridge).(CVE-2022-50470)

In the Linux kernel, the following vulnerability has been resolved:thermal: intelpowerclamp: Use getcpu() instead of smpprocessorid() to avoid crashWhen CPU 0 is offline and intelpowerclamp is used to injectidle, it generates kernel BUG:BUG: using smpprocessorid() in preemptible [00000000] code: bash/15687caller is debugsmpprocessorid+0x17/0x20CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57Call Trace:<TASK>dumpstacklvl+0x49/0x63dumpstack+0x10/0x16checkpreemptiondisabled+0xdd/0xe0debugsmpprocessorid+0x17/0x20powerclampsetcurstate+0x7f/0xf9 [intelpowerclamp]......Here CPU 0 is the control CPU by default and changed to the current CPU,if CPU 0 offlined. This check has to be performed under cpusreadlock(),hence the above warning.Use getcpu() instead of smpprocessor_id() to avoid this BUG. rjw: Subject edits

In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix pci device refcount leak in pprnotifier()As comment of pcigetdomainbusandslot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpcidevput(). So call it before returning from ppr_notifier()to avoid refcount leak.(CVE-2022-50505)

In the Linux kernel, the following vulnerability has been resolved:usb: host: xhci: Fix potential memory leak in xhciallocstreaminfo()xhciallocstreaminfo() allocates stream context array for streaminfo->streamctxarray with xhciallocstreamctx(). When some error occurs,streaminfo->streamctxarray is not released, which will lead to amemory leak.We can fix it by releasing the streaminfo->streamctxarray withxhcifreestream_ctx() on the error path to avoid the potential memoryleak.(CVE-2022-50544)

In the Linux kernel, the following vulnerability has been resolved:mtd: Fix device name leak when register device failed in addmtddevice()There is a kmemleak when register device failed: unreferenced object 0xffff888101aab550 (size 8): comm insmod , pid 3922, jiffies 4295277753 (age 925.408s) hex dump (first 8 bytes): 6d 74 64 30 00 88 ff ff mtd0.... backtrace: [<00000000bde26724>] _kmallocnodetrackcaller+0x4e/0x150 [<000000003c32b416>] kvasprintf+0xb0/0x130 [<000000001f7a8f15>] kobjectsetnamevargs+0x2f/0xb0 [<000000006e781163>] devsetname+0xab/0xe0 [<00000000e30d0c78>] addmtddevice+0x4bb/0x700 [<00000000f3d34de7>] mtddeviceparseregister+0x2ac/0x3f0 [<00000000c0d88488>] 0xffffffffa0238457 [<00000000b40d0922>] 0xffffffffa02a008f [<0000000023d17b9d>] dooneinitcall+0x87/0x2a0 [<00000000770f6ca6>] doinitmodule+0xdf/0x320 [<000000007b6768fe>] loadmodule+0x2f98/0x3330 [<00000000346bed5a>] _dosysfinitmodule+0x113/0x1b0 [<00000000674c2290>] dosyscall64+0x35/0x80 [<000000004c6a8d97>] entrySYSCALL64afterhwframe+0x46/0xb0If register device failed, should call putdevice() to give up thereference.(CVE-2022-50566)

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

ubi: ensure that VID header offset + VID header size <= alloc, size

Ensure that the VID header offset + VID header size does not exceed the allocated area to avoid slab OOB.

BUG: KASAN: slab-out-of-bounds in crc32body lib/crc32.c:111 [inline] BUG: KASAN: slab-out-of-bounds in crc32legeneric lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds in crc32le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555

CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W 6.0.0-1868 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x85/0xad lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:317 [inline] printreport.cold.13+0xb6/0x6bb mm/kasan/report.c:433 kasanreport+0xa7/0x11b mm/kasan/report.c:495 crc32body lib/crc32.c:111 [inline] crc32legeneric lib/crc32.c:179 [inline] crc32lebase+0x58c/0x626 lib/crc32.c:197 ubiiowritevidhdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067 createvtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 createemptylvol drivers/mtd/ubi/vtbl.c:500 [inline] ubireadvolumetable+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubiattach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubiattachmtddev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrlcdevioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x193/0x213 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3e/0x86 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0x0 RIP: 0033:0x7f96d5cf753d Code: RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000 </TASK>

Allocated by task 1555: kasansavestack+0x20/0x3d mm/kasan/common.c:38 kasansettrack mm/kasan/common.c:45 [inline] setallocinfo mm/kasan/common.c:437 [inline] _kasankmalloc mm/kasan/common.c:516 [inline] _kasankmalloc+0x88/0xa3 mm/kasan/common.c:525 kasankmalloc include/linux/kasan.h:234 [inline] _kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc include/linux/slab.h:605 [inline] ubiallocvidbuf drivers/mtd/ubi/ubi.h:1093 [inline] createvtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 createemptylvol drivers/mtd/ubi/vtbl.c:500 [inline] ubireadvolumetable+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubiattach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubiattachmtddev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrlcdevioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x193/0x213 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3e/0x86 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0x0

The buggy address belongs to the object at ffff88802bb36e00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff88802bb36e00, ffff88802bb36f00)

The buggy address belongs to the physical page: page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36 head:00000000ea4d1263 order:1 compoundmapcount:0 compoundpincount:0 flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001 ---truncated---(CVE-2023-53265)

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

ubi: Fix unreferenced object reported by kmemleak in ubiresizevolume()

There is a memory leaks problem reported by kmemleak:

unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<ffffffff8176cecd>] _kmalloc+0x4d/0x150 [<ffffffffa02a9a36>] ubiebacreatetable+0x76/0x170 [ubi] [<ffffffffa029764e>] ubiresizevolume+0x1be/0xbc0 [ubi] [<ffffffffa02a3321>] ubicdevioctl+0x701/0x1850 [ubi] [<ffffffff81975d2d>] _x64sysioctl+0x11d/0x170 [<ffffffff83c142a5>] dosyscall64+0x35/0x80 [<ffffffff83e0006a>] entrySYSCALL64after_hwframe+0x46/0xb0

This is due to a mismatch between create and destroy interfaces, and in detail that "newebatbl" created by ubiebacreatetable() but destroyed by kfree(), while will causing "neweba_tbl->entries" not freed.

Fix it by replacing kfree(newebatbl) with ubiebadestroytable(neweba_tbl)(CVE-2023-53271)

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

sctp: check send stream number after waitforsndbuf

This patch fixes a corner case where the asoc out stream count may change after waitforsndbuf.

When the main thread in the client starts a connection, if its out stream count is set to N while the in stream count in the server is set to N - 2, another thread in the client keeps sending the msgs with stream number N - 1, and waits for sndbuf before processing INIT_ACK.

However, after processing INIT_ACK, the out stream count in the client is shrunk to N - 2, the same to the in stream count in the server. The crash occurs when the thread waiting for sndbuf is awake and sends the msg in a non-existing stream(N - 1), the call trace is as below:

KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] Call Trace: <TASK> sctpcmdsendmsg net/sctp/smsideeffect.c:1114 [inline] sctpcmdinterpreter net/sctp/smsideeffect.c:1777 [inline] sctpsideeffects net/sctp/smsideeffect.c:1199 [inline] sctpdosm+0x197d/0x5310 net/sctp/smsideeffect.c:1170 sctpprimitiveSEND+0x9f/0xc0 net/sctp/primitive.c:163 sctpsendmsgtoasoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctpsendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inetsendmsg+0x9d/0xe0 net/ipv4/afinet.c:825 socksendmsgnosec net/socket.c:722 [inline] socksendmsg+0xde/0x190 net/socket.c:745

The fix is to add an unlikely check for the send stream number after the thread wakes up from the waitforsndbuf.(CVE-2023-53296)

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

sctp: fix a potential overflow in sctpifwdtsnskip

Currently, when traversing ifwdtsn skips with sctpwalkifwdtsn, it only checks the pos against the end of the chunk. However, the data left for the last pos may be < sizeof(struct sctpifwdtsnskip), and dereference it as struct sctpifwdtsn_skip may cause coverflow.

This patch fixes it by checking the pos against "the end of the chunk - sizeof(struct sctpifwdtsnskip)" in sctpifwdtsnskip, similar to sctpfwdtsnskip.(CVE-2023-53372)

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

wifi: mwifiex: avoid possible NULL skb pointer dereference

In 'mwifiexhandleuaprxforward()', always check the value returned by 'skbcopy()' to avoid potential NULL pointer dereference in 'mwifiexuapqueuebridged_pkt()', and drop original skb in case of copying failure.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53384)

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

drm/radeon: free iio for atombios when driver shutdown

Fix below kmemleak when unload radeon driver:

unreferenced object 0xffff9f8608ede200 (size 512): comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s) hex dump (first 32 bytes): 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000062fadebe>] kmemcachealloctrace+0x2f1/0x500 [<00000000b6883cea>] atomparse+0x117/0x230 [radeon] [<00000000158c23fd>] radeonatombiosinit+0xab/0x170 [radeon] [<00000000683f672e>] siinit+0x57/0x750 [radeon] [<00000000566cc31f>] radeondeviceinit+0x559/0x9c0 [radeon] [<0000000046efabb3>] radeondriverloadkms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drmdevregister+0xdd/0x1d0 [<0000000045fec835>] radeonpciprobe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pcideviceprobe+0xe1/0x160 [<0000000019484b76>] reallyprobe.part.0+0xc1/0x2c0 [<000000003f2649da>] _driverprobedevice+0x96/0x130 [<00000000231c5bb1>] driverprobedevice+0x24/0xf0 [<0000000000a42377>] _driverattach+0x77/0x190 [<00000000d7574da6>] busforeachdev+0x7f/0xd0 [<00000000633166d2>] driverattach+0x1e/0x30 [<00000000313b05b8>] busadddriver+0x12c/0x1e0

iio was allocated in atomindexiio() called by atomparse(), but it doesn't got released when the dirver is shutdown. Fix this kmemleak by free it in radeonatombios_fini().(CVE-2023-53453)

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

ubi: ubiwlput_peb: Fix infinite loop when wear-leveling work failed

Following process will trigger an infinite loop in ubiwlput_peb():

ubifs_bgt       ubi_bgt

ubifslebunmap ubilebunmap ubiebaunmapleb ubiwlputpeb wearlevelingworker e1 = rbentry(rbfirst(&ubi->used) e2 = getpebforwl(ubi) ubiioreadvidhdr // return err (flash fault) outerror: ubi->movefrom = ubi->moveto = NULL wlentrydestroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->lookuptbl[pnum]; // return NULL if (e == ubi->move_from) { // NULL == NULL gets true goto retry; // infinite loop !!!

$ top PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND 7676 root 20 0 0 0 0 R 100.0 0.0 ubifsbgt00

Fix it by: 1) Letting ubiwlputpeb() returns directly if wearl leveling entry has been removed from 'ubi->lookuptbl'. 2) Using 'ubi->wllock' protecting wl entry deletion to preventing an use-after-free problem for wl entry in ubiwlput_peb().

Fetch a reproducer in [Link].(CVE-2023-53481)

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

virtio-mmio: don't break lifecycle of vm_dev

vm_dev has a separate lifecycle because it has a 'struct device' embedded. Thus, having a release callback for it is correct.

Allocating the vmdev struct with devres totally breaks this protection, though. Instead of waiting for the vmdev release callback, the memory is freed when the platform_device is removed. Resulting in a use-after-free when finally the callback is to be called.

To easily see the problem, compile the kernel with CONFIGDEBUGKOBJECT_RELEASE and unbind with sysfs.

The fix is easy, don't use devres in this case.

Found during my research about object lifetime problems.(CVE-2023-53515)

In the Linux kernel, the following vulnerability has been resolved:spi: qup: Don t skip cleanup in remove s error pathReturning early in a platform driver s remove callback is wrong. In thiscase the dma resources are not released in the error path. this is neverretried later and so this is a permanent leak. To fix this, only skiphardware disabling if waking the device fails.(CVE-2023-53567)

In the Linux kernel, the following vulnerability has been resolved:dm integrity: call kmemcachedestroy() in dmintegrityinit() error pathOtherwise the journaliocache will leak if dmregistertarget() fails.(CVE-2023-53604)

In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: Fix possible NULL dereference in sndac97mixersmatch error:sound/pci/ac97/ac97codec.c:2354 sndac97_mixer() error:we previously assumed rac97 could be null (see line 2072)remove redundant assignment, return error if rac97 is NULL.(CVE-2023-53648)

In the Linux kernel, the following vulnerability has been resolved:bcache: Fix bchbtreenodealloc to make the failure behavior consistentIn some specific situations, the return value of _bchbtreenodeallocmay be NULL. This may lead to a potential NULL pointer dereference incaller function like a calling chain :btreesplit->bchbtreenodealloc->bchbtreenodealloc.Fix it by initializing the return value in _bchbtreenodealloc.(CVE-2023-53681)

In the Linux kernel, the following vulnerability has been resolved:serial: arcuart: fix ofiomap leak in arc_serial_probeSmatch reports:drivers/tty/serial/arcuart.c:631 arcserialprobe() warn: port->membase from ofiomap() not released on lines: 631.In arcserialprobe(), if uartaddoneport() fails,port->membase is not released, which would cause a resource leak.To fix this, I replace ofiomap with devmplatformioremap_resource.(CVE-2023-53719)

In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposixtimeradd() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posixtimeradd() start = sig->posixtimerid; lock(hashlock); ... posixtimeradd() if (++sig->posixtimerid < 0) start = sig->posixtimerid; sig->posixtimerid = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posixtimerid == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INTMAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)

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:

net: atm: fix /proc/net/atm/lec handling

/proc/net/atm/lec must ensure safety against dev_lec[] changes.

It appears it had devput() calls without prior devhold(), leading to imbalance and UAF.(CVE-2025-38180)

In the Linux kernel, a race condition vulnerability exists in the posix-cpu-timers component. When a non-autoreaping exiting task has passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger immediately after unlocktasksighand(). If a concurrent posixcputimerdel() runs at that moment, it will fail to detect timer->it.cpu.firing != 0 because cputimertaskrcu() and/or locktasksighand() will fail. The fix adds a tsk->exitstate check to runposixcputimers().(CVE-2025-38352)

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

ALSA: usb-audio: Validate UAC3 power domain descriptors, too

UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)

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

scsi: qla4xxx: Prevent a potential error pointer dereference

The qla4xxxgetepfwdb() function is supposed to return NULL on error, but qla4xxxep_connect() returns error pointers. Propagating the error pointers will lead to an Oops in the caller, so change the error pointers to NULL.(CVE-2025-39676)

A buffer overflow vulnerability was found in the efivarfs component of the Linux kernel. When dentry->dname.len < EFIVARIABLEGUIDLEN, &#39;guid&#39; may become negative, causing out-of-bounds reads. This vulnerability can be triggered by parallel search using invalid file names, causing kernel memory to be accessed out of bounds.(CVE-2025-39817)