OESA-2026-1341

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaallocresource(). And it s required to release the resource usingfreeresource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)

In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtwsurveydoneeventcallback()There is a deadlock in rtwsurveydoneeventcallback(),which is shown below: (Thread 1) | (Thread 2) | settimer()rtwsurveydoneeventcallback()| modtimer() spinlockbh() //(1) | (wait a time) ... | rtwscantimeouthandler() deltimersync() | spinlockbh() //(2) (wait timer to stop) | ...We hold pmlmepriv->lock in position (1) of thread 1 and usedeltimersync() to wait timer to stop, but timer handleralso need pmlmepriv->lock in position (2) of thread 2.As a result, rtwsurveydoneeventcallback() will block forever.This patch extracts deltimersync() from the protection ofspinlockbh(), which could let timer handler to obtainthe needed lock. What`s more, we change spinlockbh() inrtwscantimeouthandler() to spinlockirq(). Otherwise,spinlock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)

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

drm/scheduler: fix fence ref counting

We leaked dependency fences when processes were beeing killed.

Additional to that grab a reference to the last scheduled fence.(CVE-2022-49829)

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

usb: cdns3: fix random warning message when driver load

Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFPDMA32). Fixing up to gfp: 0xa20 (GFPATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dumpbacktrace+0x0/0x1b0 [ 4.169286] showstack+0x18/0x68 [ 4.172611] dumpstacklvl+0x68/0x84 [ 4.176286] dumpstack+0x18/0x34 [ 4.179613] kmallocfixflags+0x60/0x88 [ 4.183550] newslab+0x334/0x370 [ 4.186878] _slaballoc.part.108+0x4d4/0x748 [ 4.191419] _slaballoc.isra.109+0x30/0x78 [ 4.195702] kmemcachealloc+0x40c/0x420 [ 4.199725] dmapoolalloc+0xac/0x1f8 [ 4.203486] cdns3allocatetrbpool+0xb4/0xd0

poolallocpage(struct dmapool *pool, gfpt memflags) { ... page = kmalloc(sizeof(*page), memflags); page->vaddr = dmaalloccoherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... }

kmalloc was called with memflags, which is passed down in cdns3allocatetrbpool() and have GFPDMA32 flags. kmallfix_flags() report warning.

GFPDMA32 is not useful at all. dmaalloccoherent() will handle DMA memory region correctly by pool->dev. GFPDMA32 can be removed safely.(CVE-2022-50151)

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

of: check previous kernel's ima-kexec-buffer against memory bounds

Presently imagetkexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below:

$ sudo kexec --initrd initrd vmlinux --append='mem=16G'

<snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c000000000837974] imarestoremeasurementlist+0x94/0x6c0 LR [c00000000083b55c] imaloadkexecbuffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] imaloadkexecbuffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] imainit+0x80/0x108 [c00000000371fb70] [c0000000020514dc] initima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] dooneinitcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernelinitfreeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernelinit+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] retfromkernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---

Fix this issue by checking returned PFN range of previous kernel's ima-kexec-buffer with pageisram() to ensure correct memory bounds.(CVE-2022-50159)

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

regulator: core: Use different devices for resource allocation and DT lookup

Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/(CVE-2022-50616)

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

wifi: mt76: do not run mt76ustatusworker if the device is not running

Fix the following NULL pointer dereference avoiding to run mt76ustatusworker thread if the device is not running yet.

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: mt76 mt76utxstatusdata RIP: 0010:mt76x02macfilltxstatus.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: mt76x02sendtxstatus+0x1d2/0xeb0 mt76x02txstatusdata+0x8e/0xd0 mt76utxstatusdata+0xe1/0x240 processonework+0x92b/0x1460 workerthread+0x95/0xe00 kthread+0x3a1/0x480 retfromfork+0x1f/0x30 Modules linked in: --[ end trace 8df5d20fc5040f65 ]-- RIP: 0010:mt76x02macfilltx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554

Moreover move stat_work schedule out of the for loop.(CVE-2022-50735)

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

netfilter: allow exp not to be removed in nfctfind_expectation

Currently nfconntrackin() calling nfctfind_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches.

This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.(CVE-2023-52927)

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

firmware: dmi-sysfs: Fix null-ptr-deref in dmisysfsregister_handle

KASAN reported a null-ptr-deref error:

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 1373 Comm: modprobe Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:dmisysfsentryrelease ... Call Trace: <TASK> kobjectput dmisysfsregisterhandle (drivers/firmware/dmi-sysfs.c:540) dmisysfs dmidecodetable (drivers/firmware/dmiscan.c:133) dmiwalk (drivers/firmware/dmiscan.c:1115) dmisysfsinit (drivers/firmware/dmi-sysfs.c:149) dmisysfs dooneinitcall (init/main.c:1296) ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x4000000 from 0xffffffff81000000 ---[ end Kernel panic - not syncing: Fatal exception ]---

It is because previous patch added kobjectput() to release the memory which will call dmisysfsentryrelease() and list_del().

However, listaddtail(entry->list) is called after the error block, so the list_head is uninitialized and cannot be deleted.

Move error handling to after listaddtail to fix this.(CVE-2023-53250)

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

cacheinfo: Fix sharedcpumap to handle shared caches at different levels

The cacheinfo sets up the sharedcpumap by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched sharedcpumap when the shared cache does not have the same index between CPUs.

CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3

This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)

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

scsi: ses: Fix slab-out-of-bounds in sesintfremove()

A fix for:

BUG: KASAN: slab-out-of-bounds in sesintfremove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013

When edev->components is zero, accessing edev->component[0] members is wrong.(CVE-2023-53521)

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

driver core: fix resource leak in device_add()

When calling kobjectadd() failed in deviceadd(), it will call cleanupgluedir() to free resource. But in kobject_add(), dev->kobj.parent has been set to NULL. This will cause resource leak.

The process is as follows: deviceadd() getdeviceparent() classdircreateandadd() kobjectadd() //kobjectget() ... dev->kobj.parent = kobj; ... kobjectadd() //failed, but set dev->kobj.parent = NULL ... gluedir = getgluedir(dev) //gluedir = NULL, and goto //"Error" label ... cleanupgluedir() //becaues gluedir is NULL, not call //kobjectput()

The preceding problem may cause insmod mac80211hwsim.ko to failed. sysfs: cannot create duplicate filename '/devices/virtual/mac80211hwsim' Call Trace: <TASK> dumpstacklvl+0x8e/0xd1 sysfswarndup.cold+0x1c/0x29 sysfscreatedirns+0x224/0x280 kobjectaddinternal+0x2aa/0x880 kobjectadd+0x135/0x1a0 getdeviceparent+0x3d7/0x590 deviceadd+0x2aa/0x1cb0 devicecreategroupsvargs+0x1eb/0x260 devicecreate+0xdc/0x110 mac80211hwsimnewradio+0x31e/0x4790 [mac80211hwsim] initmac80211hwsim+0x48d/0x1000 [mac80211hwsim] dooneinitcall+0x10f/0x630 doinitmodule+0x19f/0x5e0 loadmodule+0x64b7/0x6eb0 _dosysfinitmodule+0x140/0x200 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 </TASK> kobjectaddinternal failed for mac80211hwsim with -EEXIST, don't try to register things with the same name in the same directory.(CVE-2023-53594)

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

ARM: 9317/1: kexec: Make smp stop calls asynchronous

If a panic is triggered by a hrtimer interrupt all online cpus will be notified and set offline. But as highlighted by commit 19dbdcb8039c ("smp: Warn on function calls from softirq context") this call should not be made synchronous with disabled interrupts:

softdog: Initiating panic Kernel panic - not syncing: Software Watchdog Timer expired WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smpcallfunctionmanycond unwindbacktrace: showstack dumpstacklvl _warn warnslowpathfmt smpcallfunctionmanycond smpcallfunction crashsmpsendstop.part.0 machinecrashshutdown _crashkexec panic softdogfire _hrtimerrunqueues hrtimer_interrupt

Make the smp call for machinecrashnonpanic_core() asynchronous.(CVE-2023-53712)

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

usb: early: xhci-dbc: Fix a potential out-of-bound memory access

If xdbcbulkwrite() fails, the values in 'buf' can be anything. So the string is not guaranteed to be NULL terminated when xdbc_trace() is called.

Reserve an extra byte, which will be zeroed automatically because 'buf' is a static variable, in order to avoid troubles, should it happen.(CVE-2023-53840)

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

RDMA/bnxt_re: Prevent handling any completions after qp destroy

HW may generate completions that indicates QP is destroyed. Driver should not be scheduling any more completion handlers for this QP, after the QP is destroyed. Since CQs are active during the QP destroy, driver may still schedule completion handlers. This can cause a race where the destroycq and pollcq running simultaneously.

Snippet of kernel panic while doing bnxt_re driver load unload in loop. This indicates a poll after the CQ is freed. 

[77786.481636] Call Trace: [77786.481640]  <TASK> [77786.481644]  bnxtrepollcq+0x14a/0x620 [bnxtre] [77786.481658]  ? kvmclockread+0x14/0x30 [77786.481693]  _ibprocesscq+0x57/0x190 [ibcore] [77786.481728]  ibcqpollwork+0x26/0x80 [ibcore] [77786.481761]  processonework+0x1e5/0x3f0 [77786.481768]  workerthread+0x50/0x3a0 [77786.481785]  ? _pfxworkerthread+0x10/0x10 [77786.481790]  kthread+0xe2/0x110 [77786.481794]  ? _pfxkthread+0x10/0x10 [77786.481797]  retfromfork+0x2c/0x50

To avoid this, complete all completion handlers before returning the destroy QP. If freecq is called soon after destroyqp, IB stack will cancel the CQ work before invoking the destroy_cq verb and this will prevent any race mentioned.(CVE-2023-54048)

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

bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log

It's trivial for user to trigger "verifier log line truncated" warning, as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at least two pieces of user-provided information that can be output through this buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.

Verifier log buffer should be properly sized for typical verifier state output. But it's sort-of expected that this buffer won't be long enough in some circumstances. So let's drop the check. In any case code will work correctly, at worst truncating a part of a single line output.(CVE-2023-54145)

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

driver core: fix potential null-ptr-deref in device_add()

I got the following null-ptr-deref report while doing fault injection test:

BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klistput+0x2d/0xd0 Call Trace: <TASK> klistremove+0xf1/0x1c0 devicereleasedriverinternal+0x196/0x210 busremovedevice+0x1bd/0x240 deviceadd+0xd3d/0x1100 w1addmasterdevice+0x476/0x490 [wire] ds2482probe+0x303/0x3e0 [ds2482]

This is how it happened:

w1allocdev() // The dev->driver is set to w1masterdriver. memcpy(&dev->dev, device, sizeof(struct device)); deviceadd() busadddevice() dpmsysfsadd() // It fails, calls busremove_device.

// error path
bus_remove_device()
  // The dev->driver is not null, but driver is not bound.
  __device_release_driver()
    klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.

// normal path
bus_probe_device() // It's not called yet.
  device_bind_driver()

If dev->driver is set, in the error path after calling busadddevice() in deviceadd(), busremovedevice() is called, then the device will be detached from driver. But devicebinddriver() is not called yet, so it causes null-ptr-deref while access the 'knodedriver'. To fix this, set dev->driver to null in the error path before calling busremovedevice().(CVE-2023-54321)

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

smb: client: fix use-after-free of signing key

Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race:

task A task B cifsmount() dfsmountshare() getsession() cifsmountgetsession() cifssendrecv() cifsgetsmbses() compoundsendrecv() cifssetupsession() smb2setuprequest() kfreesensitive() smb2calcsignature() cryptoshash_setkey() UAF

Fix this by ensuring that we have a valid @ses->authkey.response by checking whether @ses->sesstatus is SESGOOD or SESEXITING with @ses->seslock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2reconnectserver()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->authkey.response), so it's safe to access signing key when @ses->sesstatus == SESEXITING.(CVE-2024-53179)

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

ice: fix memory leak in aRFS after reset

Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling

However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature:

[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] _kmalloccachenoprof+0x275/0x340 [<ffffffffc0a6e06a>] iceinitarfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] icevsicfgdef+0x607/0x850 [ice] [<ffffffffc09f244b>] icevsisetup+0x5b/0x130 [ice] [<ffffffffc09c2131>] iceinit+0x1c1/0x460 [ice] [<ffffffffc09c64af>] iceprobe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] localpciprobe+0x43/0xa0 [<ffffffff98f07103>] workforcpufn+0x13/0x20 [<ffffffff98f0b6d9>] processonework+0x179/0x390 [<ffffffff98f0c1e9>] workerthread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] retfromfork+0x2d/0x50 [<ffffffff98e083ba>] retfromfork_asm+0x1a/0x30 ...(CVE-2025-21981)

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

watch_queue: fix pipe accounting mismatch

Currently, watchqueuesetsize() modifies the pipe buffers charged to user->pipebufs without updating the pipe->nraccounted on the pipe itself, due to the if (!pipehaswatchqueue()) test in piperesizering(). This means that when the pipe is ultimately freed, we decrement user->pipebufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent toomanypipebuffers_soft() tests to fail with -EPERM.

To remedy this, explicitly account for the pipe usage in watchqueuesetsize() to match the number set via accountpipe_buffers()

(It's unclear why watchqueuesetsize() does not update nraccounted; it may be due to intentional overprovisioning in watchqueueset_size()?)(CVE-2025-23138)

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

drm/amd/pm: Prevent division by zero

The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)

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

drm/amd/pm: Prevent division by zero

The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)

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

ksmbd: prevent out-of-bounds stream writes by validating *pos

ksmbdvfsstreamwrite() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (vlen). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write.

This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)

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

crypto: lzo - Fix compression buffer overrun

Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller.

Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)

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

bpf, sockmap: Avoid using sk_socket after free when sending

The sk->sksocket is not locked or referenced in backlog thread, and during the call to skbsendsock(), there is a race condition with the release of sksocket. All types of sockets(tcp/udp/unix/vsock) will be affected.

Race conditions: ''' CPU0 CPU1

backlog::skbsendsock sendmsgunlocked socksendmsg socksendmsgnosec close(fd): ... ops->release() -> sockmapclose() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

The ref of psock become 0 after sockmapclose() executed. ''' void sockmapclose() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sockmapremovelinks(sk, psock) psock = skpsockget(sk); if (unlikely(!psock)) goto nopsock; <=== Control jumps here via goto ... canceldelayedworksync(&psock->work); <=== not executed skpsock_put(sk, psock); ... } '''

Based on the fact that we already wait for the workqueue to finish in sockmapclose() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sockmapclose() will wait for the backlog thread to complete and cancel all pending work.

If no backlog running, any pending work that hasn't started by then will fail when invoked by skpsockget(), as the psock reference count have been zeroed, and skpsockdrop() will cancel all jobs via canceldelayedwork_sync().

In summary, we require synchronization to coordinate the backlog thread and close() thread.

The panic I catched: ''' Workqueue: events skpsockbacklog RIP: 0010:socksendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? dieaddr+0x40/0xa0 ? excgeneralprotection+0x14c/0x230 ? asmexcgeneralprotection+0x26/0x30 ? socksendmsg+0x21d/0x440 ? socksendmsg+0x3e0/0x440 ? _pfxsocksendmsg+0x10/0x10 _skbsendsock+0x543/0xb70 skpsock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)

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

Bluetooth: hcicore: Fix use-after-free in vhciflush()

syzbot reported use-after-free in vhci_flush() without repro. [0]

From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread.

Once the last fd refcnt is released, vhcirelease() calls hciunregisterdev(), hcifreedev(), and kfree() for struct vhcidata, which is set to hcidev->dev->driverdata.

The problem is that there is no synchronisation after unlinking hdev from hcidevlist in hciunregisterdev(). There might be another thread still accessing the hdev which was fetched before the unlink operation.

We can use SRCU for such synchronisation.

Let's run hcidevreset() under SRCU and wait for its completion in hciunregisterdev().

Another option would be to restore hcidev->destruct(), which was removed in commit 587ae086f6e4 ("Bluetooth: Remove unused hci-destruct cb"). However, this would not be a good solution, as we should not run hciunregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat.

Note that other drivers seem to have the same problem, for exmaple, virtbt_remove().

BUG: KASAN: slab-use-after-free in skbqueuepurge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718

CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xd2/0x2b0 mm/kasan/report.c:521 kasanreport+0x118/0x150 mm/kasan/report.c:634 skbqueueemptylockless include/linux/skbuff.h:1891 [inline] skbqueuepurgereason+0x99/0x360 net/core/skbuff.c:3937 skbqueuepurge include/linux/skbuff.h:3368 [inline] vhciflush+0x44/0x50 drivers/bluetooth/hcivhci.c:69 hcidevdoreset net/bluetooth/hcicore.c:552 [inline] hcidevreset+0x420/0x5c0 net/bluetooth/hcicore.c:592 sockdoioctl+0xd9/0x300 net/socket.c:1190 sockioctl+0x576/0x790 net/socket.c:1311 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xf9/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 </TASK>

Allocated by task 6535: 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] vhciopen+0x57/0x360 drivers/bluetooth/hcivhci.c:635 miscopen+0x2bc/0x330 drivers/char/misc.c:161 chrdevopen+0x4c9/0x5e0 fs/chardev.c:414 dodentryopen+0xdf0/0x1970 fs/open.c:964 vfsopen+0x3b/0x340 fs/open.c:1094 doopen fs/namei.c:3887 [inline] pathopenat+0x2ee5/0x3830 fs/name ---truncated---(CVE-2025-38250)

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

comedi: Fix use of uninitialized data in insnrwemulate_bits()

For Comedi INSN_READ and INSN_WRITE instructions on "digital" subdevices (subdevice types COMEDI_SUBD_DI, COMEDI_SUBD_DO, and COMEDI_SUBD_DIO), it is common for the subdevice driver not to have insn_read and insn_write handler functions, but to have an insn_bits handler function for handling Comedi INSN_BITS instructions. In that case, the subdevice's insn_read and/or insn_write function handler pointers are set to point to the insn_rw_emulate_bits() function by __comedi_device_postconfig().

For INSN_WRITE, insn_rw_emulate_bits() currently assumes that the supplied data[0] value is a valid copy from user memory. It will at least exist because do_insnlist_ioctl() and do_insn_ioctl() in "comedi_fops.c" ensure at lease MIN_SAMPLES (16) elements are allocated. However, if insn->n is 0 (which is allowable for INSN_READ and INSN_WRITE instructions, then data[0] may contain uninitialized data, and certainly contains invalid data, possibly from a different instruction in the array of instructions handled by do_insnlist_ioctl(). This will result in an incorrect value being written to the digital output channel (or to the digital input/output channel if configured as an output), and may be reflected in the internal saved state of the channel.

Fix it by returning 0 early if insn->n is 0, before reaching the code that accesses data[0]. Previously, the function always returned 1 on success, but it is supposed to be the number of data samples actually read or written up to insn->n, which is 0 in this case.(CVE-2025-38480)

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

HID: core: Harden s32ton() against conversion to 0 bits

Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that.

Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.(CVE-2025-38556)

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

ipv6: reject malicious packets in ipv6gsosegment()

syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.

This 16bit field has a limited range.

Add skbresettransportheadercareful() helper and use it from ipv6gsosegment()

WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skbresettransportheader include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skbresettransportheader include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Call Trace: <TASK> skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 nshgsosegment+0x54a/0xe10 net/nsh/nsh.c:110 skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 _skbgsosegment+0x342/0x510 net/core/gso.c:124 skbgsosegment include/net/gso.h:83 [inline] validatexmitskb+0x857/0x11b0 net/core/dev.c:3950 validatexmitskblist+0x84/0x120 net/core/dev.c:4000 schdirectxmit+0xd3/0x4b0 net/sched/schgeneric.c:329 _devxmitskb net/core/dev.c:4102 [inline] _devqueue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)

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

pptp: ensure minimal skb length in pptp_xmit()

Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on pppsynctxmung") fixed pppsynctxmunge()

We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.

BUG: KMSAN: uninit-value in pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2290 [inline] pppinput+0x1d6/0xe60 drivers/net/ppp/pppgeneric.c:2314 pppoercvcore+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x142/0x420 include/net/sock.h:1148 releasesock+0x1d3/0x330 net/core/sock.c:3213 releasesock+0x6b/0x270 net/core/sock.c:3767 pppoesendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg+0x330/0x3d0 net/socket.c:727 _syssendmsg+0x893/0xd80 net/socket.c:2566 _syssendmsg+0x271/0x3b0 net/socket.c:2620 _syssendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)

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

vsock: Do not allow binding to VMADDRPORTANY

It is possible for a vsock to autobind to VMADDRPORTANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDRPORTANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).

Modify the check in _vsockbindconnectible() to also prevent binding to VMADDRPORT_ANY.(CVE-2025-38618)

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

iommu/amd: Avoid stack buffer overflow from kernel cmdline

While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)

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

smb3: fix for slab out of bounds on mount to ksmbd

With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parseserverinterfaces() (see below):

BUG: KASAN: slab-out-of-bounds in parseserverinterfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827

CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dumpstacklvl+0x9f/0xf0 printreport+0xd1/0x670 _virtaddrvalid+0x22c/0x430 ? parseserverinterfaces+0x14ee/0x1880 [cifs] ? kasancompletemodereportinfo+0x2a/0x1f0 ? parseserverinterfaces+0x14ee/0x1880 [cifs] kasanreport+0xd6/0x110 parseserverinterfaces+0x14ee/0x1880 [cifs] _asanreportloadnnoabort+0x13/0x20 parseserverinterfaces+0x14ee/0x1880 [cifs] ? _pfxparseserverinterfaces+0x10/0x10 [cifs] ? tracehardirqson+0x51/0x60 SMB3requestinterfaces+0x1ad/0x3f0 [cifs] ? _pfxSMB3requestinterfaces+0x10/0x10 [cifs] ? SMB2tcon+0x23c/0x15d0 [cifs] smb3qfstcon+0x173/0x2b0 [cifs] ? _pfxsmb3qfstcon+0x10/0x10 [cifs] ? cifsgettcon+0x105d/0x2120 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifsgettcon+0x105d/0x2120 [cifs] ? _pfxsmb3qfstcon+0x10/0x10 [cifs] cifsmountgettcon+0x369/0xb90 [cifs] ? dfscachefind+0xe7/0x150 [cifs] dfsmountshare+0x985/0x2970 [cifs] ? checkpath.constprop.0+0x28/0x50 ? savetrace+0x54/0x370 ? _pfxdfsmountshare+0x10/0x10 [cifs] ? _lockacquire+0xb82/0x2ba0 ? _kasancheckwrite+0x18/0x20 cifsmount+0xbc/0x9e0 [cifs] ? _pfxcifsmount+0x10/0x10 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifssetupcifssb+0x29d/0x810 [cifs] cifssmb3do_mount+0x263/0x1990 cifs

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)

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

ipv6: sr: Fix MAC comparison to be constant-time

To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.(CVE-2025-39702)

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

rcu: Fix rcureadunlock() deadloop due to IRQ work

During rcureadunlockspecial(), if this happens during irqexit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.

This is precisely what Xiongfeng found when invoking a BPF program on the tracetickstop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.

irqexit() _irqexitrcu() /* inhardirq() returns false after this */ preemptcountsub(HARDIRQOFFSET) tickirqexit() ticknohzirqexit() ticknohzstopschedtick() tracetickstop() /* a bpf prog is hooked on this trace point */ _bpftracetickstop() bpftracerun2() rcureadunlockspecial() /* will send a IPI to itself */ irqworkqueueon(&rdp->deferqs_iw, rdp->cpu);

A simple reproducer can also be obtained by doing the following in tickirqexit(). It will hang on boot without the patch:

static inline void tickirqexit(void) { + rcureadlock(); + WRITEONCE(current->rcureadunlockspecial.b.needqs, true); + rcuread_unlock(); +

neeraj: Apply Frederic's suggested fix for PREEMPT_RT

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

rcu: Protect ->deferqsiw_pending from data race

On kernels built with CONFIGIRQWORK=y, when rcureadunlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcureadunlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.

In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.

The per-CPU rcudata structure's ->deferqsiwpending field is updated by the irq-work handler and is both read and updated by rcureadunlock_special(). This resulted in the following KCSAN splat:

BUG: KCSAN: data-race in rcupreemptdeferredqshandler / rcureadunlock_special

read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcureadunlockspecial+0x175/0x260 _rcureadunlock+0x92/0xa0 rtspinunlock+0x9b/0xc0 _localbhenable+0x10d/0x170 _localbhenableip+0xfb/0x150 rcudobatch+0x595/0xc40 rcucpukthread+0x4e9/0x830 smpbootthreadfn+0x24d/0x3b0 kthread+0x3bd/0x410 retfromfork+0x35/0x40 retfromforkasm+0x1a/0x30

write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcupreemptdeferredqshandler+0x1e/0x30 irqworksingle+0xaf/0x160 runirqworkd+0x91/0xc0 smpbootthreadfn+0x24d/0x3b0 kthread+0x3bd/0x410 retfromfork+0x35/0x40 retfromfork_asm+0x1a/0x30

no locks held by irqwork/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finishtaskswitch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] _schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0

The problem is that irq-work handlers run with interrupts enabled, which means that rcupreemptdeferredqshandler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcureadunlockspecial(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->deferqsiwpending field.

This commit therefore disables interrupts across the portion of the rcupreemptdeferredqshandler() that updates the ->deferqsiw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)

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

xfrm: Duplicate SPI Handling

The issue originates when Strongswan initiates an XFRMMSGALLOCSPI Netlink message, which triggers the kernel function xfrmallocspi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.

This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.

According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.

Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spimin = 0x10000000 spimax = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.

Current implementation: xfrmspihash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlistforeachentryrcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI

Proposed Change: xfrmstatelookupspiproto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.(CVE-2025-39797)

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

atm: atmtcp: Prevent arbitrary write in atmtcprecvcontrol().

syzbot reported the splat below. [0]

When atmtcpvopen() or atmtcpvclose() is called via connect() or close(), atmtcpsendcontrol() is called to send an in-kernel special message.

The message has ATMTCPHDRMAGIC in atmtcpcontrol.hdr.length. Also, a pointer of struct atmvcc is set to atmtcp_control.vcc.

The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.

struct atmtcpcontrol { struct atmtcphdr hdr; /* must be first / ... atm_kptr_t vcc; / both directions */ ... } _ATMAPI_ALIGN;

typedef struct { unsigned char [8]; } _ATMAPIALIGN atmkptrt;

The special message is processed in atmtcprecvcontrol() called from atmtcpcsend().

atmtcpcsend() is vcc->dev->ops->send() and called from 2 paths:

1. .ndostartxmit() (vcc->send() == atmsendaal0())
2. vcc_sendmsg()

The problem is sendmsg() does not validate the message length and userspace can abuse atmtcprecvcontrol() to overwrite any kptr by atmtcp_control.

Let's add a new ->pre_send() hook to validate messages from sendmsg().

KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcprecvcontrol drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcpcsend+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vccsendmsg+0xa10/0xc60 net/atm/common.c:645 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0x219/0x270 net/socket.c:729 syssendmsg+0x505/0x830 net/socket.c:2614 _syssendmsg+0x21f/0x2a0 net/socket.c:2668 _syssendmsg net/socket.c:2700 [inline] _dosyssendmsg net/socket.c:2705 [inline] _sesyssendmsg net/socket.c:2703 [inline] _x64syssendmsg+0x19b/0x260 net/socket.c:2703 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)

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

i40e: Fix potential invalid access when MAC list is empty

listfirstentry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.

Fix this by using listfirstentryornull instead of listfirstentry.(CVE-2025-39853)

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

Bluetooth: Fix use-after-free in l2capsockcleanup_listen()

syzbot reported the splat below without a repro.

In the splat, a single thread calling btacceptdequeue() freed sk and touched it after that.

The root cause would be the racy l2capsockcleanup_listen() call added by the cited commit.

btacceptdequeue() is called under locksock() except for l2capsock_release().

Two threads could see the same socket during the list iteration in btacceptdequeue():

CPU1 CPU2 (close()) ---- ---- sockhold(sk) sockhold(sk); locksock(sk) <-- block close() sockput(sk) btacceptunlink(sk) sockput(sk) <-- refcnt by btacceptenqueue() releasesock(sk) locksock(sk) sockput(sk) btacceptunlink(sk) sockput(sk) <-- last refcnt btaccept_unlink(sk) <-- UAF

Depending on the timing, the other thread could show up in the "Freed by task" part.

Let's call l2capsockcleanuplisten() under locksock() in l2capsockrelease().

BUG: KASAN: slab-use-after-free in dorawspinlock+0x26f/0x2b0 kernel/locking/spinlockdebug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #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 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 debugspinlockbefore kernel/locking/spinlockdebug.c:86 [inline] dorawspinlock+0x26f/0x2b0 kernel/locking/spinlockdebug.c:115 spinlockbh include/linux/spinlock.h:356 [inline] releasesock+0x21/0x220 net/core/sock.c:3746 btacceptdequeue+0x505/0x600 net/bluetooth/afbluetooth.c:312 l2capsockcleanuplisten+0x5c/0x2a0 net/bluetooth/l2capsock.c:1451 l2capsockrelease+0x5c/0x210 net/bluetooth/l2capsock.c:1425 _sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 _fput+0x3ff/0xb70 fs/filetable.c:468 taskworkrun+0x14d/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xeb/0x110 kernel/entry/common.c:43 exittousermodeprepare include/linux/irq-entry-common.h:225 [inline] syscallexittousermodework include/linux/entry-common.h:175 [inline] syscallexittousermode include/linux/entry-common.h:210 [inline] dosyscall64+0x3f6/0x4c0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>

Allocated by task 5326: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:388 [inline] _kasankmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasankmalloc include/linux/kasan.h:260 [inline] _dokmallocnode mm/slub.c:4365 [inline] _kmallocnopro ---truncated---(CVE-2025-39860)

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

tcpbpf: Call skmsgfree() when tcpbpfsendverdict() fails to allocate psock->cork.

syzbot reported the splat below. [0]

The repro does the following:

1. Load a skmsg prog that calls bpfmsgcorkbytes(msg, cork_bytes)
2. Attach the prog to a SOCKMAP
3. Add a socket to the SOCKMAP
4. Activate fault injection
5. Send data less than cork_bytes

At 5., the data is carried over to the next sendmsg() as it is smaller than the corkbytes specified by bpfmsgcorkbytes().

Then, tcpbpfsendverdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + _GFP_NOWARN.

If the allocation fails, we need to revert the sk->skforwardalloc change done by skmsgalloc().

Let's call skmsgfree() when tcpbpfsend_verdict fails to allocate psock->cork.

The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.

Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inetsockdestruct+0x623/0x730 net/ipv4/afinet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> _skdestruct+0x86/0x660 net/core/sock.c:2339 rcudobatch kernel/rcu/tree.c:2605 [inline] rcucore+0xca8/0x1770 kernel/rcu/tree.c:2861 handlesoftirqs+0x286/0x870 kernel/softirq.c:579 _dosoftirq kernel/softirq.c:613 [inline] invokesoftirq kernel/softirq.c:453 [inline] _irqexitrcu+0xca/0x1f0 kernel/softirq.c:680 irqexitrcu+0x9/0x30 kernel/softirq.c:696 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvecapictimerinterrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)

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

cnic: Fix use-after-free bugs in cnicdeletetask

The original code uses canceldelayedwork() in cniccmstopbnx2xhw(), which does not guarantee that the delayed work item 'deletetask' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flushworkqueue() in cniccmstopbnx2xhw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flushworkqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnicdev is deallocated by cnicfreedev(), while deletetask remains active and attempt to dereference cnicdev in cnicdeletetask().

A typical race condition is illustrated below:

CPU 0 (cleanup) | CPU 1 (delayed work callback) cnicnetdevevent() | cnicstophw() | cnicdeletetask() cniccmstopbnx2xhw() | ... canceldelayedwork() | /* the queuedelayedwork() flushworkqueue() | executes after flushworkqueue()*/ | queuedelayedwork() cnicfreedev(dev)//free | cnicdeletetask() //new instance | dev = cp->dev; //use

Replace canceldelayedwork() with canceldelayedworksync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnicdev is deallocated. Furthermore, since canceldelayedworksync() uses _flushwork(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flushworkqueue() becomes redundant and should be removed.

This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnicdeletetask() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)

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

ipvs: Defer ipvsftp unregister during netns cleanup

On the netns cleanup path, _ipvsftpexit() may unregister ipvsftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.

Fix this by introducing a global exiting_module flag, set to true in ipvsftpexit() before unregistering the pernet subsystem. In _ipvsftpexit(), skip ipvsftp unregister if called during netns cleanup (when exitingmodule is false) and defer it to _ipvscleanupbatch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ipvsftp immediately.(CVE-2025-40018)

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

vfs: Don't leak disconnected dentries on umount

When user calls openbyhandleat() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfsdecodefhraw() will then try to connect this dentry to the dentry tree through reconnectpath(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookuponeunlocked() in reconnectone() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on danon") which removed adding of most disconnected dentries to sb->sanon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)

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

xfrm: delete x->tunnel as we delete x

The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrmstatefini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.

We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrmstatefini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.

Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.

A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.(CVE-2025-40215)

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

fs/proc: fix uaf in procreaddirde()

Pde is erased from subdir rbtree through rberase(), but not set the node to EMPTY, which may result in uaf access. We should use RBCLEARNODE() set the erased node to EMPTY, then pdesubdir_next() will return NULL to avoid uaf access.

We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:

1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;

2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;

3) continue to getdent process, then pdesubdirnext() will return pde(tun2) which is released, it will case uaf access.

CPU 0 | CPU 1

traverse dir /proc/pid/net/devsnmp6/ | unregisternetdevice(tun->dev) //tun3 tun2 sysgetdents64() | iteratedir() | procreaddir() | procreaddirde() | snmp6unregisterdev() pdeget(de); | procremove() readunlock(&procsubdirlock); | removeprocsubtree() | writelock(&procsubdirlock); [time window] | rberase(&root->subdirnode, &parent->subdir); | writeunlock(&procsubdirlock); readlock(&procsubdirlock); | next = pdesubdirnext(de); | pdeput(de); | de = next; //UAF |

rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)

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

tipc: Fix use-after-free in tipcmonreinit_self().

syzbot reported use-after-free of tipcnet(net)->monitors[] in tipcmonreinitself(). [0]

The array is protected by RTNL, but tipcmonreinit_self() iterates over it without RTNL.

tipcmonreinitself() is called from tipcnetfinalize(), which is always under RTNL except for tipcnetfinalizework().

Let's hold RTNL in tipcnetfinalize_work().

BUG: KASAN: slab-use-after-free in rawspinlockirqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989

CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipcnetfinalizework Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 _kasancheckbyte+0x2a/0x40 mm/kasan/common.c:568 kasancheckbyte include/linux/kasan.h:399 [inline] lockacquire+0x8d/0x360 kernel/locking/lockdep.c:5842 _rawspinlockirqsave include/linux/spinlockapismp.h:110 [inline] _rawspinlockirqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlockslowlock kernel/locking/rtmutex.c:1894 [inline] rwbasertmutexlockstate kernel/locking/spinlockrt.c:160 [inline] rwbasewritelock+0xd3/0x7e0 kernel/locking/rwbasert.c:244 rtwritelock+0x76/0x110 kernel/locking/spinlockrt.c:243 writelockbh include/linux/rwlockrt.h:99 [inline] tipcmonreinitself+0x79/0x430 net/tipc/monitor.c:718 tipcnetfinalize+0x115/0x190 net/tipc/net.c:140 processonework kernel/workqueue.c:3236 [inline] processscheduledworks+0xade/0x17b0 kernel/workqueue.c:3319 workerthread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 retfromfork+0x439/0x7d0 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

Allocated by task 6089: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3e/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:388 [inline] kasankmalloc+0x93/0xb0 mm/kasan/common.c:405 kasankmalloc include/linux/kasan.h:260 [inline] _kmalloccachenoprof+0x1a8/0x320 mm/slub.c:4407 kmallocnoprof include/linux/slab.h:905 [inline] kzallocnoprof include/linux/slab.h:1039 [inline] tipcmoncreate+0xc3/0x4d0 net/tipc/monitor.c:657 tipcenablebearer net/tipc/bearer.c:357 [inline] _tipcnlbearerenable+0xe16/0x13f0 net/tipc/bearer.c:1047 _tipcnlcompatdoit net/tipc/netlinkcompat.c:371 [inline] tipcnlcompatdoit+0x3bc/0x5f0 net/tipc/netlinkcompat.c:393 tipcnlcompathandle net/tipc/netlinkcompat.c:-1 [inline] tipcnlcompatrecv+0x83c/0xbe0 net/tipc/netlinkcompat.c:1321 genlfamilyrcvmsgdoit+0x215/0x300 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x60e/0x790 net/netlink/genetlink.c:1210 netlinkrcvskb+0x208/0x470 net/netlink/afnetlink.c:2552 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1320 [inline] netlinkunicast+0x846/0xa10 net/netlink/afnetlink.c:1346 netlinksendmsg+0x805/0xb30 net/netlink/afnetlink.c:1896 socksendmsgnosec net/socket.c:714 [inline] _socksendmsg+0x21c/0x270 net/socket.c:729 syssendmsg+0x508/0x820 net/socket.c:2614 _syssendmsg+0x21f/0x2a0 net/socket.c:2668 _syssendmsg net/socket.c:2700 [inline] _dosyssendmsg net/socket.c:2705 [inline] _sesyssendmsg net/socket.c:2703 [inline] _x64syssendmsg+0x1a1/0x260 net/socket.c:2703 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/ ---truncated---(CVE-2025-40280)

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

nvme-fc: use lock accessing port_state and rport state

nvmefcunregisterremote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvmefccreateassociation is not taking a lock to check the port_state and atomically increase the active count on the rport.(CVE-2025-40342)

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

archtopology: Fix incorrect error check in topologyparsecpucapacity()

Fix incorrect use of PTRERRORZERO() in topologyparsecpucapacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTRERRORZERO(cpuclk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clkgetrate().

Per include/linux/err.h documentation, PTRERROR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."

This means PTRERRORZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTRERRORZERO(cpuclk) evaluates to true (proceed) when cpuclk is either valid or NULL, causing clkgetrate(NULL) to be called when ofclkget() returns NULL.

Replace with !ISERRORNULL(cpuclk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clkgetrate().(CVE-2025-40346)

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

net: usb: qmiwwan: initialize MAC header offset in qmimuxrx_fixup

Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks.

Initialize the MAC header to prevent such crashes.

This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface.

Example trace:

Internal error: Oops: 000000009600004f [#1] SMP
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
Hardware name: LS1028A RDB Board (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xfrm_input+0xde8/0x1318
lr : xfrm_input+0x61c/0x1318
sp : ffff800080003b20
Call trace:
 xfrm_input+0xde8/0x1318
 xfrm6_rcv+0x38/0x44
 xfrm6_esp_rcv+0x48/0xa8
 ip6_protocol_deliver_rcu+0x94/0x4b0
 ip6_input_finish+0x44/0x70
 ip6_input+0x44/0xc0
 ipv6_rcv+0x6c/0x114
 __netif_receive_skb_one_core+0x5c/0x8c
 __netif_receive_skb+0x18/0x60
 process_backlog+0x78/0x17c
 __napi_poll+0x38/0x180
 net_rx_action+0x168/0x2f0(CVE-2025-68192)

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

libceph: fix potential use-after-free in havemonandosdmap()

The wait loop in _cephopensession() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both cephmonchandlemap() and handleonemap() install a new map immediately after freeing the old one

kfree(monc->monmap);
monc->monmap = monmap;

ceph_osdmap_destroy(osdc->osdmap);
osdc->osdmap = newmap;

under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in havemonandosdmap() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in

client->monc.monmap && client->monc.monmap->epoch &&
    client->osdc.osdmap && client->osdc.osdmap->epoch;

condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:

BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
...
Call Trace:
<TASK>
have_mon_and_osd_map+0x56/0x70
ceph_open_session+0x182/0x290
ceph_get_tree+0x333/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>

Allocated by task 13305:
ceph_osdmap_alloc+0x16/0x130
ceph_osdc_init+0x27a/0x4c0
ceph_create_client+0x153/0x190
create_fs_client+0x50/0x2a0
ceph_get_tree+0xff/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 9475:
kfree+0x212/0x290
handle_one_map+0x23c/0x3b0
ceph_osdc_handle_map+0x3c9/0x590
mon_dispatch+0x655/0x6f0
ceph_con_process_message+0xc3/0xe0
ceph_con_v1_try_read+0x614/0x760
ceph_con_workfn+0x2de/0x650
process_one_work+0x486/0x7c0
process_scheduled_works+0x73/0x90
worker_thread+0x1c8/0x2a0
kthread+0x2ec/0x300
ret_from_fork+0x24/0x40
ret_from_fork_asm+0x1a/0x30

Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mounttimeout could be exceeded in case waiteventinterruptibletimeout() slept more than once) and access client->autherr under client->monc.mutex to match how it's set in finishauth().

monmapshow() and osdmapshow() now take the respective lock before accessing the map as well.(CVE-2025-68285)

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

media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100i2cmsg()

rlen value is a user-controlled value, but dtv5100i2cmsg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.

Therefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)

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

RDMA/cm: Fix leaking the multicast GID table reference

If the CM ID is destroyed while the CM event for multicast creating is still queued the cancelworksync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN:

GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 releasegidtable drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gidtablerelease_one+0x284/0x3cc drivers/infiniband/core/cache.c:886

Destroy the ah_attr after canceling the work, it is safe to call this twice.(CVE-2025-71084)

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

team: fix check for port enabled in teamqueueoverrideportprio_changed()

There has been a syzkaller bug reported recently with the following trace:

listdel corruption, ffff888058bea080->prev is LISTPOISON2 (dead000000000122) ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:59! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #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 RIP: 0010:listdelentryvalidorreport+0x13e/0x200 lib/listdebug.c:59 Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0 Call Trace: <TASK> _listdelentryvalid include/linux/list.h:132 [inline] _listdelentry include/linux/list.h:223 [inline] listdelrcu include/linux/rculist.h:178 [inline] _teamqueueoverrideportdel drivers/net/team/teamcore.c:826 [inline] _teamqueueoverrideportdel drivers/net/team/teamcore.c:821 [inline] teamqueueoverrideportpriochanged drivers/net/team/teamcore.c:883 [inline] teampriorityoptionset+0x171/0x2f0 drivers/net/team/teamcore.c:1534 teamoptionset drivers/net/team/teamcore.c:376 [inline] teamnloptionssetdoit+0x8ae/0xe60 drivers/net/team/teamcore.c:2653 genlfamilyrcvmsgdoit+0x209/0x2f0 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x55c/0x800 net/netlink/genetlink.c:1210 netlinkrcvskb+0x158/0x420 net/netlink/afnetlink.c:2552 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1320 [inline] netlinkunicast+0x5aa/0x870 net/netlink/afnetlink.c:1346 netlinksendmsg+0x8c8/0xdd0 net/netlink/afnetlink.c:1896 socksendmsgnosec net/socket.c:727 [inline] _socksendmsg net/socket.c:742 [inline] syssendmsg+0xa98/0xc70 net/socket.c:2630 _syssendmsg+0x134/0x1d0 net/socket.c:2684 _syssendmsg+0x16d/0x220 net/socket.c:2716 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xfa0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

The problem is in this flow: 1) Port is enabled, queueid != 0, in qomlist 2) Port gets disabled -> teamportdisable() -> teamqueueoverrideportdel() -> del (removed from list) 3) Port is disabled, queueid != 0, not in any list 4) Priority changes -> teamqueueoverrideportpriochanged() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed already

To fix this, change the check in teamqueueoverrideportprio_changed() so it returns early if port is not enabled.(CVE-2025-71091)

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

SUNRPC: svcauthgss: avoid NULL deref on zero length gsstoken in gssreadproxy_verf

A zero length gsstoken results in pages == 0 and intoken->pages[0] is NULL. The code unconditionally evaluates pageaddress(intoken->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.(CVE-2025-71120)

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

nvme-tcp: fix NULL pointer dereferences in nvmettcpbuildpduiovec

Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and dataoffset validation in nvmettcphandleh2cdatapdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs.

The nvmettcpbuildpduiovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.

Attack vectors that trigger NULL pointer dereferences: 1. H2CDATA PDU sent before CONNECT → both pointers NULL 2. H2CDATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL

The fix validates both cmd->req.sg and cmd->iov before calling nvmettcpbuildpduiovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated(CVE-2026-22998)

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

pnfs/flexfiles: Fix memory leak in nfs4ffallocdeviceidnode()

In nfs4ffallocdeviceidnode(), if the allocation for dsversions fails, the function jumps to the outscratch label without freeing the already allocated dsaddrs list, leading to a memory leak.

Fix this by jumping to the outerrdrain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)