The Linux Kernel, the operating system core itself.

Security Fix(es):

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

iommu/s390: Implement blocking domain

This fixes a crash when surprise hot-unplugging a PCI device. This crash happens because during hot-unplug __iommugroupsetdomainnofail() attaching the default domain fails when the platform no longer recognizes the device as it has already been removed and we end up with a NULL domain pointer and UAF. This is exactly the case referred to in the second comment in _iommudevicesetdomain() and just as stated there if we can instead attach the blocking domain the UAF is prevented as this can handle the already removed device. Implement the blocking domain to use this handling. With this change, the crash is fixed but we still hit a warning attempting to change DMA ownership on a blocked device.(CVE-2024-53232)

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

iommu: Fix two issues in iommucopystructfromuser()

In the review for iommucopystructtouser() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/(CVE-2025-37900)

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

smb: client: Avoid race in opencacheddir with lease breaks

A pre-existing valid cfid returned from findorcreatecacheddir might race with a lease break, meaning opencacheddir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs.

Avoid the race by extending holding the cfidlistlock across findorcreatecacheddir and when the result is checked.(CVE-2025-37954)

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

netsched: prio: fix a race in priotune()

Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time.

The race is as follows:

CPU 0 CPU 1 | | [5]: lock root | [6]: rehash | [7]: qdisctreereduce_backlog() | This can be abused to underflow a parent's qlen.

Calling qdiscpurgequeue() instead of qdisctreeflush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.(CVE-2025-38083)

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

IB/mlx5: Fix potential deadlock in MR deregistration

The issue arises when kzalloc() is invoked while holding umemmutex or any other lock acquired under umemmutex. This is problematic because kzalloc() can trigger fsreclaimaqcuire(), which may, in turn, invoke mmunotifierinvalidaterangestart(). This function can lead to mlx5ibinvalidaterange(), which attempts to acquire umemmutex again, resulting in a deadlock.

The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5ibderegmr() | → revokemr() | → mutexlock(&umemodp->umemmutex) | | mlx5mkeycacheinit() | → mutexlock(&dev->cache.rblock) | → mlx5rcachecreateentlocked() | → kzalloc(GFPKERNEL) | → fsreclaim() | → mmunotifierinvalidaterangestart() | → mlx5ibinvalidaterange() | → mutexlock(&umemodp->umemmutex) → cacheentfindandstore() | → mutexlock(&dev->cache.rblock) |

Additionally, when kzalloc() is called from within cacheentfindandstore(), we encounter the same deadlock due to re-acquisition of umem_mutex.

Solve by releasing umemmutex in deregmr() after umrrevokemr() and before acquiring rblock. This ensures that we don't hold umemmutex while performing memory allocations that could trigger the reclaim path.

This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path.

The following lockdep warning demonstrates the deadlock:

python3/20557 is trying to acquire lock: ffff888387542128 (&umemodp->umemmutex){+.+.}-{4:4}, at: mlx5ibinvalidaterange+0x5b/0x550 [mlx5ib]

but task is already holding lock: ffffffff82f6b840 (mmunotifierinvalidaterangestart){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (mmunotifierinvalidaterangestart){+.+.}-{0:0}: fsreclaimacquire+0x60/0xd0 memcgroupcssalloc+0x6f/0x9b0 cgroupinitsubsys+0xa4/0x240 cgroupinit+0x1c8/0x510 startkernel+0x747/0x760 x8664startreservations+0x25/0x30 x8664startkernel+0x73/0x80 commonstartup_64+0x129/0x138

-> #2 (fsreclaim){+.+.}-{0:0}: fsreclaim_acquire+0x91/0xd0 __kmalloccachenoprof+0x4d/0x4c0 mlx5rcachecreateentlocked+0x75/0x620 [mlx5ib] mlx5mkeycacheinit+0x186/0x360 [mlx5ib] mlx5ibstagepostibregumrinit+0x3c/0x60 [mlx5_ib] __mlx5ibadd+0x4b/0x190 [mlx5ib] mlx5rprobe+0xd9/0x320 [mlx5ib] auxiliarybusprobe+0x42/0x70 reallyprobe+0xdb/0x360 __driverprobedevice+0x8f/0x130 driverprobedevice+0x1f/0xb0 __driverattach+0xd4/0x1f0 busforeachdev+0x79/0xd0 busadddriver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliarydriverregister+0x6a/0xc0 dooneinitcall+0x5e/0x390 doinitmodule+0x88/0x240 initmodulefromfile+0x85/0xc0 idempotentinit_module+0x104/0x300 _x64sysfinitmodule+0x68/0xc0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53

-> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5ibderegmr+0x6f2/0x890 [mlx5ib] mlx5ibderegmr+0x21/0x110 [mlx5ib] ibderegmruser+0x85/0x1f0 [ibcore]

---truncated---(CVE-2025-38373)

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:

bpf: Reject narrower access to pointer ctx fields

The following BPF program, simplified from a syzkaller repro, causes a kernel warning:

r0 = *(u8 *)(r1 + 169);
exit;

With pointer field sk being at offset 168 in __skbuff. This access is detected as a narrower read in bpfskb_isvalidaccess because it doesn't match offsetof(struct __skbuff, sk). It is therefore allowed and later proceeds to bpfconvertctxaccess. Note that for the "isnarrowerload" case in the convertctxaccesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct _skbuff, sk) in the bpfconvertctxaccess. However, the targetsize stays 0 and the verifier errors with a kernel warning:

verifier bug: error during ctx access conversion(1)

This patch fixes that to return a proper "invalid bpf_context access off=X size=Y" error on the load instruction.

The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for skmsg, sklookup, and sockopt) were also changed to use bpfctxrange_ptr for consistency.

Note this syzkaller crash was reported in the "Closes" link below, which used to be about a different bug, fixed in commit fce7bd8e385a ("bpf/verifier: Handle BPFLOADACQ instructions in insndefregno()"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.(CVE-2025-38591)

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

gfs2: No more self recovery

When a node withdraws and it turns out that it is the only node that has the filesystem mounted, gfs2 currently tries to replay the local journal to bring the filesystem back into a consistent state. Not only is that a very bad idea, it has also never worked because gfs2recoverfunc() will refuse to do anything during a withdraw.

However, before even getting to this point, gfs2recoverfunc() dereferences sdp->sdjdesc->jdinode. This was a use-after-free before commit 04133b607a78 ("gfs2: Prevent double iput for journal on error") and is a NULL pointer dereference since then.

Simply get rid of self recovery to fix that.(CVE-2025-38659)

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

io_uring/net: commit partial buffers on retry

Ring provided buffers are potentially only valid within the single execution context in which they were acquired. iouring deals with this and invalidates them on retry. But on the networking side, if MSGWAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons:

1) If someone unregisters the provided buffer ring before a later retry, then the req->buf_list will no longer be valid.

2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.

Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used.(CVE-2025-38730)

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

media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()

In the interrupt handler raininterrupt(), the buffer full check on rain->buflen is performed before acquiring rain->buflock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buflen is concurrently accessed and modified in the work handler rainirqwork_handler() under the same lock.

Multiple interrupt invocations can race, with each reading buflen before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buflen beyond its capacity (DATA_SIZE) and causing a buffer overflow.

Fix this bug by moving the spinlock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spinunlock() is added to the overflow path to correctly release the lock.

This possible bug was found by an experimental static analysis tool developed by our team.(CVE-2025-39713)

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

iommu/amd/pgtbl: Fix possible race while increase page table level

The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in allocpte()/fetchpte() operations.

The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.

But in unmap path (iommuv1unmappages()), fetchpte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increaseaddressspace() is updating pgtable->[root/mode], fetchpte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommuunmap ops to fail and upper layer may retry/log WARN_ON.

CPU 0 CPU 1 ------ ------ map pages unmap pages allocpte() -> increaseaddressspace() iommuv1unmappages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)

Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.(CVE-2025-39961)

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

pinctrl: check the return value of pinmuxops::getfunction_name()

While the API contract in docs doesn't specify it explicitly, the generic implementation of the getfunctionname() callback from struct pinmuxops - pinmuxgenericgetfunctionname() - can fail and return NULL. This is already checked in pinmuxcheckops() so add a similar check in pinmuxfuncnameto_selector() instead of passing the returned pointer right down to strcmp() where the NULL can get dereferenced. This is normal operation when adding new pinfunctions.(CVE-2025-40030)

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

drm/sched: Fix potential double free in drmschedjobaddresv_dependencies

When adding dependencies with drmschedjobadddependency(), that function consumes the fence reference both on success and failure, so in the latter case the dmafenceput() on the error path (xarray failed to expand) is a double free.

Interestingly this bug appears to have been present ever since commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code back then looked like this:

drmschedjobaddimplicitdependencies(): ... for (i = 0; i < fencecount; i++) { ret = drmschedjobadddependency(job, fences[i]); if (ret) break; }

   for (; i < fence_count; i++)
           dma_fence_put(fences[i]);

Which means for the failing 'i' the dmafenceput was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it.

The bug was then only noticed and fixed after commit 9c2ba265352a ("drm/scheduler: use new iterator in drmschedjobaddimplicitdependencies v2") landed, with its fixup of commit 4eaf02d6076c ("drm/scheduler: fix drmschedjobaddimplicitdependencies").

At that point it was a slightly different flavour of a double free, which commit 963d0b356935 ("drm/scheduler: fix drmschedjobaddimplicit_dependencies harder") noticed and attempted to fix.

But it only moved the double free from happening inside the drmschedjobadddependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case.

As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain.

While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.(CVE-2025-40096)

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:

fuse: fix livelock in synchronous file put from fuseblk workers

I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server:

cat /proc/372265/task/372313/stack

[<0>] requestwaitanswer+0x1fe/0x2a0 [fuse] [<0>] __fusesimplerequest+0xd3/0x2b0 [fuse] [<0>] fusedogetattr+0xfc/0x1f0 [fuse] [<0>] fusefilereaditer+0xbe/0x1c0 [fuse] [<0>] aioread+0x130/0x1e0 [<0>] iosubmitone+0x542/0x860 [<0>] _x64sysiosubmit+0x98/0x1a0 [<0>] dosyscall64+0x37/0xf0 [<0>] entrySYSCALL64afterhwframe+0x4b/0x53

But the /weird/ part is that the fuseblk server threads are waiting for responses from itself:

cat /proc/372210/task/372232/stack

[<0>] requestwaitanswer+0x1fe/0x2a0 [fuse] [<0>] __fusesimplerequest+0xd3/0x2b0 [fuse] [<0>] fuse_fileput+0x9a/0xd0 [fuse] [<0>] fuserelease+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] taskworkrun+0x55/0x90 [<0>] syscallexittousermode+0xe9/0x100 [<0>] dosyscall64+0x43/0xf0 [<0>] entrySYSCALL64afterhwframe+0x4b/0x53

The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fusefileput? The commit message for the fstest sheds some light on that:

"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).

Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.

Sending the FUSERELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayedfput, and now there aren't any threads left to handle the queued fuse commands.

Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.(CVE-2025-40220)

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

fs/notify: call exportfsencodefid with s_umount

Calling intotifyshowfdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr.

This issue was found by syzkaller.

Race Condition Diagram:

Thread 1 Thread 2 -------- --------

genericshutdownsuper() shrinkdcacheforumount sb->sroot = NULL

                |
                |             vfs_read()
                |              inotify_fdinfo()
                |               * inode get from mark *
                |               show_mark_fhandle(m, inode)
                |                exportfs_encode_fid(inode, ..)
                |                 ovl_encode_fh(inode, ..)
                |                  ovl_check_encode_origin(inode)
                |                   * deref i_sb->s_root *
                |
                |
                v

fsnotifysbdelete(sb)

Which then leads to:

[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)

<snip registers, unreliable trace>

[ 32.143353] Call Trace: [ 32.143732] ovlencodefh+0xd5/0x170 [ 32.144031] exportfsencodeinodefh+0x12f/0x300 [ 32.144425] showmarkfhandle+0xbe/0x1f0 [ 32.145805] inotifyfdinfo+0x226/0x2d0 [ 32.146442] inotifyshowfdinfo+0x1c5/0x350 [ 32.147168] seqshow+0x530/0x6f0 [ 32.147449] seqreaditer+0x503/0x12a0 [ 32.148419] seqread+0x31f/0x410 [ 32.150714] vfsread+0x1f0/0x9e0 [ 32.152297] ksysread+0x125/0x240

IOW ovlcheckencodeorigin derefs inode->isb->s_root, after it was set to NULL in the unmount path.

Fix it by protecting calling exportfsencodefid() from showmarkfhandle() with s_umount lock.

This form of fix was suggested by Amir in [1].

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

gfs2: Fix unlikely race in gdlmputlock

In gdlmputlock(), there is a small window of time in which the DFLUNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlmast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.(CVE-2025-40242)

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

devlink: rate: Unset parent pointer in devlratenodes_destroy

The function devlratenodes_destroy is documented to "Unset parent for all rate objects". However, it was only calling the driver-specific rate_leaf_parent_set or rate_node_parent_set ops and decrementing the parent's refcount, without actually setting the devlink_rate->parent pointer to NULL.

This leaves a dangling pointer in the devlink_rate struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of devlink_nl_rate_parent_node_set, where the parent pointer is correctly cleared.

This patch fixes the issue by explicitly setting devlink_rate->parent to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects.

[1] repro steps: echo 1 > /sys/bus/netdevsim/newdevice devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriovnumvfs devlink port function rate add netdevsim/netdevsim1/testnode devlink port function rate set netdevsim/netdevsim1/128 parent testnode echo 1 > /sys/bus/netdevsim/del_device

dmesg: refcountt: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcountwarnsaturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcountwarnsaturate+0x42/0xe0 Call Trace: <TASK> devlrateleafdestroy+0x8d/0x90 __nsimdevportdel+0x6c/0x70 [netdevsim] nsimdevreloaddestroy+0x11c/0x140 [netdevsim] nsimdrvremove+0x2b/0xb0 [netdevsim] devicereleasedriverinternal+0x194/0x1f0 busremovedevice+0xc6/0x130 devicedel+0x159/0x3c0 deviceunregister+0x1a/0x60 deldevicestore+0x111/0x170 [netdevsim] kernfsfopwriteiter+0x12e/0x1e0 vfswrite+0x215/0x3d0 ksyswrite+0x5f/0xd0 dosyscall64+0x55/0x10f0 entrySYSCALL64afterhwframe+0x4b/0x53

[2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5ib mlx5fwctl mlx5_core

dmesg: refcountt: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcountwarnsaturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7forupstreammindebug202510021244 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcountwarnsaturate+0x42/0xe0 Call Trace: <TASK> devlrateleafdestroy+0x8d/0x90 mlx5eswoffloadsdevlinkportunregister+0x33/0x60 [mlx5core] mlx5eswoffloadsunloadrep+0x3f/0x50 [mlx5core] mlx5eswitchunloadsfvport+0x40/0x90 [mlx5core] mlx5sfeswevent+0xc4/0x120 [mlx5core] notifiercallchain+0x33/0xa0 blockingnotifiercallchain+0x3b/0x50 mlx5eswitchdisablelocked+0x50/0x110 [mlx5core] mlx5eswitchdisable+0x63/0x90 [mlx5core] mlx5unload+0x1d/0x170 [mlx5core] mlx5uninitone+0xa2/0x130 [mlx5core] removeone+0x78/0xd0 [mlx5core] pcideviceremove+0x39/0xa0 devicereleasedriverinternal+0x194/0x1f0 unbindstore+0x99/0xa0 kernfsfopwriteiter+0x12e/0x1e0 vfswrite+0x215/0x3d0 ksyswrite+0x5f/0xd0 dosyscall64+0x53/0x1f0 entrySYSCALL64after_hwframe+0x4b/0x53(CVE-2025-40251)

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:

mm/secretmem: fix use-after-free race in fault handler

When a page fault occurs in a secret memory file created with memfd_secret(2), the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping.

If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping.

If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault.

Fix the ordering to restore the direct map before the folio is freed.(CVE-2025-40272)

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

drm/vmwgfx: Validate command header size against SVGACMDMAX_DATASIZE

This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.(CVE-2025-40277)

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

Bluetooth: MGMT: Fix OOB access in parseadvmonitor_pattern()

In the parseadvmonitorpattern() function, the value of the 'length' variable is currently limited to HCIMAXEXTADLENGTH(251). The size of the 'value' array in the mgmtadv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied.

Increasing the size of the 'value' array in the 'mgmtadvpattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCIMAXAD_LENGTH.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40294)

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

Bluetooth: hci_event: validate skb length for unknown CC opcode

In hcicmdcompleteevt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hcievent_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory.

The fix is to check skb->len before using skb->data.(CVE-2025-40301)

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

Bluetooth: bcsp: receive data only if registered

Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace:

KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
Call Trace:
 <TASK>
 hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

To prevent this, ensure that the HCIUARTREGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.(CVE-2025-40308)

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

Bluetooth: hcisync: fix race in hcicmdsyncdequeue_once

hcicmdsyncdequeueonce() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hcicmdsyncwork() can also delete the same entry, leading to double listdel() and "UAF".

Fix this by holding cmdsyncwork_lock across both lookup and cancel, so that the entry cannot be removed concurrently.(CVE-2025-40318)

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

futex: Don't leak robust_list pointer on exec race

sysgetrobustlist() and compatgetrobustlist() use ptracemayaccess() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process.

During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If getrobustlist() performs ptracemayaccess() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged.

A racy access allows an attacker to exploit a window during which ptracemayaccess() passes before a target process transitions to a privileged state via exec().

For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls getrobustlist(T) while T is still unprivileged. Since ptracemayaccess() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because getrobustlist() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process.

This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk.

Take a read lock on signal->execupdatelock prior to invoking ptracemayaccess() and accessing the robustlist/compatrobust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.(CVE-2025-40341)

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:

nvmet-fc: avoid scheduling association deletion twice

When forcefully shutting down a port via the configfs interface, nvmetportsubsysdroplink() first calls nvmetportdelctrls() and then nvmetdisable_port(). Both functions will eventually schedule all remaining associations for deletion.

The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.

Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.(CVE-2025-40343)

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:

hfsplus: fix KMSAN uninit-value issue in hfsplusdeletecat()

The syzbot reported issue in hfsplusdeletecat():

[ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplussubfoldersdec+0x1d7/0x220 [ 70.683640][ T9333] hfsplussubfoldersdec+0x1d7/0x220 [ 70.684141][ T9333] hfsplusdeletecat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplusrmdir+0x13d/0x310 [ 70.685048][ T9333] vfsrmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64sysrmdir+0x71/0xb0 [ 70.686260][ T9333] x64syscall+0xcd8/0x3cf0 [ 70.686695][ T9333] dosyscall64+0xd9/0x1d0 [ 70.687119][ T9333] entrySYSCALL64afterhwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplussubfoldersinc+0x1c2/0x1d0 [ 70.688779][ T9333] hfspluscreatecat+0x148e/0x1800 [ 70.689231][ T9333] hfsplusmknod+0x27f/0x600 [ 70.689730][ T9333] hfsplusmkdir+0x5a/0x70 [ 70.690146][ T9333] vfsmkdir+0x483/0x7a0 [ 70.690545][ T9333] domkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64sysmkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_syscall+0x2f89/0x3cf0 [ 70.691816][ T9333] dosyscall64+0xd9/0x1d0 [ 70.692229][ T9333] entrySYSCALL64afterhwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplussubfoldersinc+0x1c2/0x1d0 [ 70.693960][ T9333] hfspluscreatecat+0x148e/0x1800 [ 70.694438][ T9333] hfsplusfillsuper+0x21c1/0x2700 [ 70.694911][ T9333] mountbdev+0x37b/0x530 [ 70.695320][ T9333] hfsplusmount+0x4d/0x60 [ 70.695729][ T9333] legacygettree+0x113/0x2c0 [ 70.696167][ T9333] vfsgettree+0xb3/0x5c0 [ 70.696588][ T9333] donewmount+0x73e/0x1630 [ 70.697013][ T9333] pathmount+0x6e3/0x1eb0 [ 70.697425][ T9333] __sesysmount+0x733/0x830 [ 70.697857][ T9333] __x64sysmount+0xe4/0x150 [ 70.698269][ T9333] x64syscall+0x2691/0x3cf0 [ 70.698704][ T9333] dosyscall64+0xd9/0x1d0 [ 70.699117][ T9333] entrySYSCALL64afterhwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __allocpagesnoprof+0x714/0xe60 [ 70.700843][ T9333] allocpagesmpolnoprof+0x2a2/0x9b0 [ 70.701331][ T9333] allocpagesnoprof+0xf8/0x1f0 [ 70.701774][ T9333] allocateslab+0x30e/0x1390 [ 70.702194][ T9333] ___slaballoc+0x1049/0x33a0 [ 70.702635][ T9333] kmemcachealloclrunoprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplusallocinode+0x5a/0xd0 [ 70.703598][ T9333] allocinode+0x82/0x490 [ 70.703984][ T9333] igetlocked+0x22e/0x1320 [ 70.704428][ T9333] hfsplusiget+0x5c/0xba0 [ 70.704827][ T9333] hfsplusbtreeopen+0x135/0x1dd0 [ 70.705291][ T9333] hfsplusfillsuper+0x1132/0x2700 [ 70.705776][ T9333] mountbdev+0x37b/0x530 [ 70.706171][ T9333] hfsplusmount+0x4d/0x60 [ 70.706579][ T9333] legacygettree+0x113/0x2c0 [ 70.707019][ T9333] vfsgettree+0xb3/0x5c0 [ 70.707444][ T9333] donewmount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __sesysmount+0x733/0x830 [ 70.708711][ T9333] __x64sysmount+0xe4/0x150 [ 70.709158][ T9333] x64syscall+0x2691/0x3cf0 [ 70.709630][ T9333] dosyscall64+0xd9/0x1d0 [ 70.710053][ T9333] entrySYSCALL64afterhwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---(CVE-2025-40351)

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

riscv: stacktrace: Disable KASAN checks for non-current tasks

Unwinding the stack of a task other than current, KASAN would report "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"

There is a same issue on x86 and has been resolved by the commit 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks") The solution could be applied to RISC-V too.

This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23

[(CVE-2025-40358)

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

perf/x86/intel: Fix KASAN global-out-of-bounds warning

When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen.

================================================================== BUG: KASAN: global-out-of-bounds in cmtlatencydata+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850

Call Trace:

kasanreport+0xb8/0xf0 cmtlatencydata+0x176/0x1b0 setuparchpebssampledata+0xf49/0x2560 intelpmudrainarchpebs+0x577/0xb00 handlepmi_common+0x6c4/0xc80

The issue is caused by below code in __grtlatencydata(). The code tries to access x86hybridpmu structure which doesn't exist on non-hybrid platform like CWF.

    WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)

So add ishybrid() check before calling this WARNON_ONCE to fix the global-out-of-bounds access issue.(CVE-2025-40359)

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

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

x86/fpu: Ensure XFD state on signal delivery

Sean reported [1] the following splat when running KVM tests:

WARNING: CPU: 232 PID: 15391 at xfdvalidatestate+0x65/0x70 Call Trace: <TASK> fpu__clearuserstates+0x9c/0x100 archdosignalorrestart+0x142/0x210 exittousermodeloop+0x55/0x100 dosyscall64+0x205/0x2c0 entrySYSCALL64afterhwframe+0x4b/0x53

Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR.

When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clearuserstates() does not currently re-synchronize the XFD state after such preemption.

Invoke xfdupdatestate() which detects and corrects the mismatch if there is a dynamic feature.

This also benefits the sigreturn path, as fpurestore_sig() may call fpuclearuserstates() when the sigframe is inaccessible.

dhansen: minor changelog munging

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

ftrace: Fix softlockup in ftracemoduleenable

A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsymslookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPTVOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add condresched() to ftracegraphsethash()").

Fix it the same way by adding condresched() in ftracemodule_enable.(CVE-2025-68173)

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

amd/amdkfd: enhance kfd process check in switch partition

current switch partition only check if kfdprocessestable is empty. kfdprcessestable entry is deleted in kfdprocessnotifierrelease, but kfdprocess tear down is in kfdprocesswq_release.

consider two processes:

Process A (workqueue) -> kfdprocesswqrelease -> Access kfdnode member Process B switch partition -> amdgpuxcpprepartitionswitch -> amdgpuamdkfddevicefinisw -> kfd_node tear down.

Process A and B may trigger a race as shown in dmesg log.

This patch is to resolve the race by adding an atomic kfdprocess counter kfdprocessescount, it increment as create kfd process, decrement as finish kfdprocesswqrelease.

v2: Put kfdprocessescount per kfddev, move decrement to kfdprocessdestroypdds and bug fix. (Philip Yang)

[3966658.307702] divide error: 0000 [#1] SMP NOPTI [3966658.350818] i10nmedac [3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted [3966658.356890] Workqueue: kfdprocesswq kfdprocesswqrelease [amdgpu] [3966658.362839] nfit [3966658.366457] RIP: 0010:kfdgetnumsdmaengines+0x17/0x40 [amdgpu] [3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 <f7> be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00 [3966658.380967] x86pkgtempthermal [3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246 [3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000 [3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00 [3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4 [3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000 [3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800 [3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000 [3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0 [3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [3966658.391536] PKRU: 55555554 [3966658.391536] Call Trace: [3966658.391674] deallocatesdmaqueue+0x38/0xa0 [amdgpu] [3966658.391762] processterminationcpsch+0x1ed/0x480 [amdgpu] [3966658.399754] intelpowerclamp [3966658.402831] kfdprocessdequeuefromalldevices+0x5b/0xc0 [amdgpu] [3966658.402908] kfdprocesswqrelease+0x1a/0x1a0 [amdgpu] [3966658.410516] coretemp [3966658.434016] processonework+0x1ad/0x380 [3966658.434021] workerthread+0x49/0x310 [3966658.438963] kvmintel [3966658.446041] ? processonework+0x380/0x380 [3966658.446045] kthread+0x118/0x140 [3966658.446047] ? __kthreadbindmask+0x60/0x60 [3966658.446050] retfromfork+0x1f/0x30 [3966658.446053] Modules linked in: kpatch20765354(OEK) [3966658.455310] kvm [3966658.464534] mptcpdiag xskdiag rawdiag unixdiag afpacketdiag netlinkdiag udpdiag actpedit actmirred actvlan clsflower kpatch21951273(OEK) kpatch18424469(OEK) kpatch19749756(OEK) [3966658.473462] idxdmdev [3966658.482306] kpatch17971294(OEK) schingress xtconntrack amdgpu(OE) amdxcp(OE) amddrmbuddy(OE) amdsched(OE) amdttm(OE) amdkcl(OE) intelifs iptablemangle tcmloop targetcorepscsi tcpdiag targetcorefile inetdiag targetcoreiblock targetcoreuser targetcoremod coldpgs kpatch18383292(OEK) ip6tablenat ip6tablefilter ip6tables ipsethashipportip ipsethashipportnet ipsethashipport ipsetbitmapport xtcomment iptablenat nfnat iptablefilter iptables ipset ipvssh ipvswrr ipvsrr ipvs nfconntrack nfdefragipv6 nfdefragipv4 sncoreodd(OE) i40e overlay binfmtmisc tun bonding(OE) aisqos(OE) aisqo ---truncated---(CVE-2025-68174)

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

PCI: cadence: Check for the existence of cdns_pcie::ops before using it

cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops.

Hence, add a check to prevent NULL pointer dereference.

mani: reworded subject and description

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

tcp: use dstdevrcu() in tcpfastopenactivedisableofo_check()

Use RCU to avoid a pair of atomic operations and a potential UAF on dst_dev()->flags.(CVE-2025-68188)

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

bpf: Add bpfprogrundatapointers()

syzbot found that clsbpfclassify() is able to change tcskbcb(skb)->dropreason triggering a warning in skskbreasondrop().

WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __skskbreasondrop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 skskbreasondrop+0x76/0x170 net/core/skbuff.c:1214

struct tcskbcb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and dataend for clsact_bpf").

drop_reason was added later.

Add bpfprogrundatapointers() helper to save/restore the netsched storage colliding with BPF datameta/data_end.(CVE-2025-68200)

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

netfilter: nft_ct: add seqadj extension for natted connections

Sequence adjustment may be required for FTP traffic with PASV/EPSV modes. due to need to re-write packet payload (IP, port) on the ftp control connection. This can require changes to the TCP length and expected seq / ack_seq.

The easiest way to reproduce this issue is with PASV mode. Example ruleset: table inet ftpnat { ct helper ftphelper { type "ftp" protocol tcp l3proto inet }

    chain prerouting {
            type filter hook prerouting priority 0; policy accept;
            tcp dport 21 ct state new ct helper set "ftp_helper"
    }

} table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } }

    chain postrouting {
            type nat hook postrouting priority 100 ; policy accept;
            tcp sport 21 snat ip prefix to ip saddr map {
        192.168.13.2 : 192.168.100.1/32 }
    }

}

Note that the ftp helper gets assigned after the dnat setup.

The inverse (nat after helper assign) is handled by an existing check in nfnatsetup_info() and will not show the problem.

Topoloy:

+-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+

ftp nat changes do not work as expected in this case: Connected to 192.168.100.1. [..] ftp> epsv EPSV/EPRT on IPv4 off. ftp> ls 227 Entering passive mode (192,168,100,1,209,129). 421 Service not available, remote server has closed connection.

Kernel logs: Missing nfctseqadjextadd() setup call WARNING: CPU: 1 PID: 0 at net/netfilter/nfconntrack_seqadj.c:41 [..] _nfnatmangletcppacket+0x100/0x160 [nfnat] nfnatftp+0x142/0x280 [nfnatftp] help+0x4d1/0x880 [nfconntrackftp] nfconfirm+0x122/0x2e0 [nfconntrack] nfhookslow+0x3c/0xb0 ..

Fix this by adding the required extension when a conntrack helper is assigned to a connection that has a nat binding.(CVE-2025-68206)

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

bpf: account for current allocated stack depth in widenimprecisescalars()

The usage pattern for widenimprecisescalars() looks as follows:

prev_st = find_prev_entry(env, ...);
queued_st = push_stack(...);
widen_imprecise_scalars(env, prev_st, queued_st);

Where prevst is an ancestor of the queuedst in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case:

def main():
  for i in 1..2:
    foo(i)        // same callsite, differnt param

def foo(i):
  if i == 1:
    use 128 bytes of stack
  iterator based loop

Here, for a second 'foo' call prevst->allocatedstack is 128, while queuedst->allocatedstack is much smaller. widenimprecisescalars() needs to take this into account and avoid accessing bpfverifierstate->frame[*]->stack out of bounds.(CVE-2025-68208)

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

nouveau/firmware: Add missing kfree() of nvkmfalconfw::boot

nvkmfalconfw::boot is allocated, but no one frees it. This causes a kmemleak warning.

Make sure this data is deallocated.(CVE-2025-68235)

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

KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced

When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP.

As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP.

The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests. Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism. To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream. If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction. If the RIP is incorrect, then this lookup fails and the guest kernel panics.

The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch[1] while running a drgn script[2] on the host to constantly swap out the memory containing the guest's TSS.

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

ext4: add idatasem protection in ext4destroyinlinedatanolock()

Fix a race between inline data destruction and block mapping.

The function ext4destroyinlinedatanolock() changes the inode data layout by clearing EXT4INODEINLINEDATA and setting EXT4INODEEXTENTS. At the same time, another thread may execute ext4mapblocks(), which tests EXT4INODEEXTENTS to decide whether to call ext4extmapblocks() or ext4indmap_blocks().

Without idatasem protection, ext4indmapblocks() may receive inode with EXT4INODE_EXTENTS flag and triggering assert.

kernel BUG at fs/ext4/indirect.c:546! EXT4-fs (loop2): unmounting filesystem. invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:ext4indmap_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546

Call Trace: <TASK> ext4mapblocks+0xb9b/0x16f0 fs/ext4/inode.c:681 ext4getblock+0x242/0x590 fs/ext4/inode.c:822 ext4blockwritebegin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4writebegin+0x598/0xef0 fs/ext4/inode.c:1255 ext4dawritebegin+0x21e/0x9c0 fs/ext4/inode.c:3000 genericperformwrite+0x259/0x5d0 mm/filemap.c:3846 ext4bufferedwriteiter+0x15b/0x470 fs/ext4/file.c:285 ext4filewriteiter+0x8e0/0x17f0 fs/ext4/file.c:679 callwriteiter include/linux/fs.h:2271 [inline] doiterreadvwritev+0x212/0x3c0 fs/readwrite.c:735 doiterwrite+0x186/0x710 fs/readwrite.c:861 vfsiterwrite+0x70/0xa0 fs/readwrite.c:902 iterfilesplicewrite+0x73b/0xc90 fs/splice.c:685 dosplicefrom fs/splice.c:763 [inline] directspliceactor+0x10f/0x170 fs/splice.c:950 splicedirecttoactor+0x33a/0xa10 fs/splice.c:896 dosplicedirect+0x1a9/0x280 fs/splice.c:1002 dosendfile+0xb13/0x12c0 fs/read_write.c:1255 __dosyssendfile64 fs/read_write.c:1323 [inline] __sesyssendfile64 fs/read_write.c:1309 [inline] _x64syssendfile64+0x1cf/0x210 fs/readwrite.c:1309 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8(CVE-2025-68261)

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

ext4: refresh inline data size before write operations

The cached ei->iinlinesize can become stale between the initial size check and when ext4updateinlinedata()/ext4createinlinedata() use it. Although ext4getmaxinlinesize() reads the correct value at the time of the check, concurrent xattr operations can modify iinlinesize before ext4writelock_xattr() is acquired.

This causes ext4updateinlinedata() and ext4createinlinedata() to work with stale capacity values, leading to a BUGON() crash in ext4writeinlinedata():

kernel BUG at fs/ext4/inline.c:1331! BUGON(pos + len > EXT4I(inode)->iinlinesize);

The race window: 1. ext4getmaxinlinesize() reads iinlinesize = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, iinlinesize changes to 40] 4. ext4writelockxattr() acquires lock 5. ext4updateinlinedata() uses stale iinlinesize = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers

Fix this by recalculating iinlinesize via ext4findinlinedatanolock() immediately after acquiring xattrsem. This ensures ext4updateinlinedata() and ext4createinline_data() work with current values that are protected from concurrent modifications.

This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inlinedata file while its xattrs are changing") which fixed iinlineoff staleness. This patch addresses the related iinline_size staleness issue.(CVE-2025-68264)

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

nvme: fix admin request_queue lifetime

The namespaces can access the controller's admin requestqueue, and stale references on the namespaces may exist after tearing down the controller. Ensure the admin requestqueue is active by moving the controller's 'put' to after all controller references have been released to ensure no one is can access the request_queue. This fixes a reported use-after-free bug:

BUG: KASAN: slab-use-after-free in blkqueueenter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNEDMODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: <TASK> dumpstacklvl+0x4f/0x60 printreport+0xc4/0x620 ? rawspinlockirqsave+0x70/0xb0 ? rawreadunlockirqrestore+0x30/0x30 ? blkqueueenter+0x41c/0x4a0 kasanreport+0xab/0xe0 ? blkqueueenter+0x41c/0x4a0 blkqueue_enter+0x41c/0x4a0 ? __irqworkqueuelocal+0x75/0x1d0 ? blkqueuestartdrain+0x70/0x70 ? irqworkqueue+0x18/0x20 ? vprintkemit.part.0+0x1cc/0x350 ? wakeupklogdworkfunc+0x60/0x60 blkmqallocrequest+0x2b7/0x6b0 ? __blkmqalloc_requests+0x1060/0x1060 ? __switchto+0x5b7/0x1060 nvmesubmitusercmd+0xa9/0x330 nvmeusercmd.isra.0+0x240/0x3f0 ? forcesigsegv+0xe0/0xe0 ? nvmeusercmd64+0x400/0x400 ? vfsfileattrset+0x9b0/0x9b0 ? cgroupupdatefrozenflag+0x24/0x1c0 ? cgroupleavefrozen+0x204/0x330 ? nvmeioctl+0x7c/0x2c0 blkdevioctl+0x1a8/0x4d0 ? blkdevcommonioctl+0x1930/0x1930 ? fdget+0x54/0x380 _x64sysioctl+0x129/0x190 dosyscall64+0x5b/0x160 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60 </TASK>(CVE-2025-68265)

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

ceph: fix crash in processv2sparse_read() for encrypted directories

The crash in processv2sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps:

sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure

(1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp areadecrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=rawkey --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered

[ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messengerv2.c:865 cephconv2tryread+0x4b39/0x72f0 [ 408.072267] Modules linked in: intelraplmsr intelraplcommon inteluncorefrequencycommon intelpmccore pmttelemetry pmtdiscovery pmtclass intelpmcssramtelemetry intelvsec kvmintel joydev kvm irqbypass polyvalclmulni ghashclmulniintel aesniintel rapl inputleds psmouse serioraw i2cpiix4 vga16fb bochs vgastate i2csmbus floppy machid qemufwcfg pataacpi schfqcodel rbd msr parportpc ppdev lp parport efipstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr cephconworkfn [ 408.072314] RIP: 0010:cephconv2tryread+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] <TASK> [ 408.072340] ? schedclocknoinstr+0x9/0x10 [ 408.072344] ? __pfxcephconv2tryread+0x10/0x10 [ 408.072347] ? rawspinunlock+0xe/0x40 [ 408.072349] ? finishtaskswitch.isra.0+0x15d/0x830 [ 408.072353] ? __kasancheckwrite+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfxmutexlock+0x10/0x10 [ 408.072361] cephconworkfn+0x27e/0x10e0 [ 408.072364] ? metricdelayedwork+0x311/0x2c50 [ 408.072367] processonework+0x611/0xe20 [ 408.072371] ? __kasancheckwrite+0x14/0x30 [ 408.072373] workerthread+0x7e3/0x1580 [ 408.072375] ? pfxrawspinlockirqsave+0x10/0x10 [ 408.072378] ? __pfxworkerthread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? pfxrawspinlock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasancheckwrite+0x14/0x30 [ 408.072389] ? recalcsigpending+0x160/0x220 [ 408.072392] ? rawspinunlockirq+0xe/0x50 [ 408.072394] ? calculatesigpending+0x78/0xb0 [ 408.072395] ? __pfxkthread+0x10/0x10 [ 408.072397] retfrom_fork+0x2b6/0x380 [ 408.072400] ? __pfxkthread+0x10/0x10 [ 408.072402] retfromforkasm+0x1a/0x30 [ 408.072406] </TASK> [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---(CVE-2025-68297)

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

net: atlantic: fix fragment overflow handling in RX path

The atlantic driver can receive packets with more than MAXSKBFRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skbaddrxfragnetmem() leading to kernel panic.

The issue occurs because the driver doesn't check the total number of fragments before calling skbaddrxfrag(). When a packet requires more than MAXSKB_FRAGS fragments, the fragment index exceeds the array bounds.

Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path.

This crash occurred in production with an Aquantia AQC113 10G NIC.

Stack trace from production environment:

RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0
Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89
ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90
c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48
89 fa 83
RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287
RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:
fffffffe0a0c8000
RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:
0000000000037a40
RBP: 0000000000000024 R08: 0000000000000000 R09:
0000000000000021
R10: 0000000000000848 R11: 0000000000000000 R12:
ffffa9bec02a8e24
R13: ffff925ad8615570 R14: 0000000000000000 R15:
ffff925b22e80a00
FS: 0000000000000000(0000)
GS:ffff925e47880000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:
0000000000f72ef0
PKRU: 55555554
Call Trace:
<IRQ>
aq_ring_rx_clean+0x175/0xe60 [atlantic]
? aq_ring_rx_clean+0x14d/0xe60 [atlantic]
? aq_ring_tx_clean+0xdf/0x190 [atlantic]
? kmem_cache_free+0x348/0x450
? aq_vec_poll+0x81/0x1d0 [atlantic]
? __napi_poll+0x28/0x1c0
? net_rx_action+0x337/0x420

Changes in v4: - Add Fixes: tag to satisfy patch validation requirements.

Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for.(CVE-2025-68301)

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

PCI/AER: Fix NULL pointer access by aer_info

The kzalloc(GFPKERNEL) may return NULL, so all accesses to aerinfo->xxx will result in kernel panic. Fix it.(CVE-2025-68309)

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

usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer

When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dmadirectunmapsg() function is called within the usbhcdunmapurbfordma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed.

The SCSI driver sends transfer commands by invoking uasqueuecommandlck() in uas.c, using the uassubmiturbs() function to submit requests to USB. Within the uassubmiturbs() implementation, three URBs (senseurb, dataurb, and cmdurb) are sequentially submitted. Device removal may occur at any point during uassubmiturbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uassubmiturbs will return the -ENODEV error code in this case. The current error handling directly calls scsidone(). In the SCSI driver, this eventually triggers scsicomplete() to invoke scsiendrequest() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usbhcdunmapurbfordma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed.

This patch modifies the error condition check in the uassubmiturbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsidone() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsidone() function will be called within uastrycomplete() after all pending URB operations are finalized. Otherwise, the scsidone() function will be called within uaszappending(), which is executed after usbkillanchoredurbs().

The error handling only takes effect when uasqueuecommandlck() calls uassubmiturbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uasdisconnect(), where uaszappending() is invoked to call uastry_complete().(CVE-2025-68331)

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

jbd2: avoid bugon in jbd2journalgetcreate_access() when file system corrupted

There's issue when file system corrupted: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1289! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next RIP: 0010:jbd2journalgetcreateaccess+0x3b6/0x4d0 RSP: 0018:ffff888117aafa30 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534 RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010 RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0 Call Trace: <TASK> __ext4journalget_createaccess+0x42/0x170 ext4getblk+0x319/0x6f0 ext4bread+0x11/0x100 ext4append+0x1e6/0x4a0 ext4initnewdir+0x145/0x1d0 ext4mkdir+0x326/0x920 vfsmkdir+0x45c/0x740 domkdirat+0x234/0x2f0 __x64sysmkdir+0xd6/0x120 dosyscall64+0x5f/0xfa0 entrySYSCALL64afterhwframe+0x76/0x7e

The above issue occurs with us in errors=continue mode when accompanied by storage failures. There have been many inconsistencies in the file system data. In the case of file system data inconsistency, for example, if the block bitmap of a referenced block is not set, it can lead to the situation where a block being committed is allocated and used again. As a result, the following condition will not be satisfied then trigger BUGON. Of course, it is entirely possible to construct a problematic image that can trigger this BUGON through specific operations. In fact, I have constructed such an image and easily reproduced this issue. Therefore, JASSERT() holds true only under ideal conditions, but it may not necessarily be satisfied in exceptional scenarios. Using JASSERT() directly in abnormal situations would cause the system to crash, which is clearly not what we want. So here we directly trigger a JBD abort instead of immediately invoking BUG_ON.(CVE-2025-68337)

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

NFSv4/pNFS: Clear NFSINOLAYOUTCOMMIT in pnfsmarklayoutstateidinvalid

Fixes a crash when layout is null during this call stack:

writeinode -> nfs4writeinode -> pnfslayoutcommit_inode

pnfssetlayoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFSINOLAYOUTCOMMIT otherwise we might attempt to reference a null layout.(CVE-2025-68349)

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

regulator: core: Protect regulatorsupplyaliaslist with regulatorlist_mutex

regulatorsupplyaliaslist was accessed without any locking in regulatorsupplyalias(), regulatorregistersupplyalias(), and regulatorunregistersupply_alias(). Concurrent registration, unregistration and lookups can race, leading to:

1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.

Protect all traversals, insertions and deletions on regulatorsupplyaliaslist with the existing regulatorlist_mutex.(CVE-2025-68354)

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

gfs2: Prevent recursive memory reclaim

Function newinode() returns a new inode with inode->imapping->gfpmask set to GFPHIGHUSER_MOVABLE. This value includes the _GFPFS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory.

Worse than that is that it can also deadlock: for example, in several places, gfs2unstuffdinode() is called inside filesystem transactions. This calls filemapgrabfolio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue.

To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include _GFPFS.

The "meta" and resource group address spaces were already using GFPNOFS as their gfpmask (which doesn't include __GFPFS). The default value of GFPHIGHUSERMOVABLE is less restrictive than GFPNOFS, though. To avoid being overly limiting, use the default value and only knock off the _GFPFS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt.

This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation").

Fixes xfstest generic/273.(CVE-2025-68356)

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

wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187rxcb()

The rtl8187rxcb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header.

If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic.

Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.(CVE-2025-68362)

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

bpf: Check skb->transportheader is set in bpfskbcheckmtu

The bpfskbcheckmtu helper needs to use skb->transportheader when the BPFMTUCHK_SEGS flag is used:

bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)

The transportheader is not always set. There is a WARNONONCE report when CONFIGDEBUGNET is enabled + skb->gsosize is set + bpfprogtest_run is used:

WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skbgsovalidatenetworklen bpfskbcheckmtu bpfprog3920e25740a41171tcchksegsflag # A test in the next patch bpftestrun bpfprogtestrun_skb

For a normal ingress skb (not testrun), skbresettransportheader is performed but there is plan to avoid setting it as described in commit 2170a1f09148 ("net: no longer reset transport_header in _netifreceiveskbcore()").

This patch fixes the bpf helper by checking skbtransportheaderwasset(). The check is done just before skb->transportheader is used, to avoid breaking the existing bpf prog. The WARNONONCE is limited to bpfprogtestrun, so targeting bpf-next.(CVE-2025-68363)

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

coresight: ETR: Fix ETR buffer use-after-free issue

When ETR is enabled as CSMODESYSFS, if the buffer size is changed and enabled again, currently sysfsbuf will point to the newly allocated memory(bufnew) and free the old memory(bufold). But the etrbuf that is being used by the ETR remains pointed to bufold, not updated to bufnew. In this case, it will result in a memory use-after-free issue.

Fix this by checking ETR's mode before updating and releasing bufold, if the mode is CSMODE_SYSFS, then skip updating and releasing it.(CVE-2025-68376)

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

bpf: Fix stackmap overflow check in __bpfgetstackid()

Syzkaller reported a KASAN slab-out-of-bounds write in __bpfgetstackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.(CVE-2025-68378)

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

crypto: asymmetrickeys - prevent overflow in asymmetrickeygenerateid

Use checkaddoverflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetrickeyid structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.(CVE-2025-68724)

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

bpf: Do not let BPF test infra emit invalid GSO types to stack

Yinhao et al. reported that their fuzzer tool was able to trigger a skbwarnbadoffload() from netifskbfeatures() -> gsofeaturescheck(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpfclone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled.

We get into this situation due to convert__skbtoskb() setting gsosegs and gsosize but not gsotype. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gsotype. Potentially, the gsotype could be marked non-trustworthy through setting it at least to SKBGSODODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place.

The checks were added in 121d57af308d ("gso: validate gsotype in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gsotype. If we would want to drop such packets, gsofeaturescheck() currently only returns feature flags via netifskbfeatures(), so one location for potentially dropping such skbs could be validatexmitunreadableskb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpfclone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.(CVE-2025-68725)

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

isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()

In hfcsusbprobe(), the memory allocated for ctrlurb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style.

Compile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)

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

scsi: qla2xxx: Fix improper freeing of purex item

In qla2xxxprocesspurlsiocb(), an item is allocated via qla27xxcopymultiplepkt(), which internally calls qla24xxallocpurex_item().

The qla24xxallocpurex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().

An error handling path in qla2xxxprocesspurls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.

Fix this by using the correct deallocation function, qla24xxfreepurex_item(), which properly handles both dynamically allocated and pre-allocated items.(CVE-2025-68741)

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

bpf: Free special fields when update [lru_,]percpu_hash maps

As [lru_,]percpuhash maps support BPFKPTR_{REF,PERCPU}, missing calls to 'bpfobjfreefields()' in 'pcpucopyvalue()' could cause the memory referenced by BPFKPTR_{REF,PERCPU} fields to be held until the map gets freed.

Fix this by calling 'bpfobjfreefields()' after 'copymapvalue,_long' in 'pcpucopy_value()'.(CVE-2025-68744)

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

scsi: qla2xxx: Clear cmds after chip reset

Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:

1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.

2. BUGON(cmd->sgmapped) in qltfreecmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qltunmapsg() at the same time: BUGON(!validdmadirection(dir)) in dmaunmapsgattrs().

So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at _qla2x00abortallcmds.(CVE-2025-68745)

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

block: Use RCU in blkmq[un]quiescetagset() instead of set->taglist_lock

blkmq{add,del}queuetagset() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blkmqaddqueuetagset() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blkmqdelqueuetag_set() need to mark both the tagset and the remaining queues as unshared.

Both functions need to freeze current queues in tagset before setting on unsetting BLKMQFTAGQUEUESHARED flag. While doing so, both functions hold set->taglistlock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c ("nvme: use blkmq_[un]quiescetagset") made the nvme driver quiesce tagset instead of quiscing individual queues. blkmqquiescetagset() does the job and quiesce the queues in set->taglist while holding set->taglist_lock also.

This results in deadlock between two threads with these stacktraces:

__schedule+0x47c/0xbb0 ? timerqueueadd+0x66/0xb0 schedule+0x1c/0xa0 schedulepreempt_disabled+0xa/0x10 __mutexlock.constprop.0+0x271/0x600 blkmqquiescetagset+0x25/0xc0 nvmedevdisable+0x9c/0x250 nvmetimeout+0x1fc/0x520 blkmqhandleexpired+0x5c/0x90 btiter+0x7e/0x90 blkmqqueuetagbusyiter+0x27e/0x550 ? __blkmqcompleterequestremote+0x10/0x10 ? __blkmqcompleterequestremote+0x10/0x10 ? __callrcucommon.constprop.0+0x1c0/0x210 blkmqtimeoutwork+0x12d/0x170 processonework+0x12e/0x2d0 workerthread+0x288/0x3a0 ? rescuerthread+0x480/0x480 kthread+0xb8/0xe0 ? kthreadpark+0x80/0x80 retfromfork+0x2d/0x50 ? kthreadpark+0x80/0x80 retfromforkasm+0x11/0x20

_schedule+0x47c/0xbb0 ? xasfind+0x161/0x1a0 schedule+0x1c/0xa0 blkmqfreezequeuewait+0x3d/0x70 ? destroyscheddomainsrcu+0x30/0x30 blkmqupdatetagsetshared+0x44/0x80 blkmqexitqueue+0x141/0x150 delgendisk+0x25a/0x2d0 nvmensremove+0xc9/0x170 nvmeremovenamespaces+0xc7/0x100 nvmeremove+0x62/0x150 pcideviceremove+0x23/0x60 devicereleasedriverinternal+0x159/0x200 unbindstore+0x99/0xa0 kernfsfopwriteiter+0x112/0x1e0 vfswrite+0x2b1/0x3d0 ksyswrite+0x4e/0xb0 dosyscall64+0x5b/0x160 entrySYSCALL64afterhwframe+0x4b/0x53

The top stacktrace is showing nvmetimeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blkmqquiescetagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->taglistlock as it tries to walk the queues in set->tag_list.

The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever.

Given that [un]quiescing queue is an operation that does not need to sleep, update blkmq[un]quiescetagset() to use RCU instead of taking set->taglistlock, update blkmq_{add,del}queuetagset() to use RCU safe list operations. Also, delete INITLISTHEAD(&q->tagsetlist) in blkmqdelqueuetagset() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blkfreequeue() after the end of RCU grace period.(CVE-2025-68756)

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

sched/deadline: only set free_cpus for online runqueues

Commit 16b269436b72 ("sched/deadline: Modify cpudl::freecpus to reflect rd->online") introduced the cpudlset/clearfreecpu functions to allow the cpudl::freecpus mask to be manipulated by the deadline scheduler class rqon/offline callbacks so the mask would also reflect this state.

Commit 9659e1eeee28 ("sched/deadline: Remove cpuactivemask from cpudlfind()") removed the check of the cpuactivemask to save some processing on the premise that the cpudl::freecpus mask already reflected the runqueue online state.

Unfortunately, there are cases where it is possible for the cpudlclear function to set the freecpus bit for a CPU when the deadline runqueue is offline. When this occurs while a CPU is connected to the default root domain the flag may retain the bad state after the CPU has been unplugged. Later, a different CPU that is transitioning through the default root domain may push a deadline task to the powered down CPU when cpudlfind sees its freecpus bit is set. If this happens the task will not have the opportunity to run.

One example is outlined here: https://lore.kernel.org/lkml/(CVE-2025-68780)

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

scsi: target: Reset ttaskcdb pointer in error case

If allocation of cmd->ttaskcdb fails, it remains NULL but is later dereferenced in the 'err' path.

In case of error, reset NULL ttaskcdb value to point at the default fixed-size buffer.

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

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

iomap: adjust read range correctly for non-block-aligned positions

iomapadjustread_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio.

Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.(CVE-2025-68794)

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

NFSD: NFSv4 file creation neglects setting ACL

An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: "the ACL attribute is set as given".

The issue occurs in nfsdcreatesetattr(), which calls nfsdattrsvalid() to determine whether to call nfsdsetattr(). However, nfsdattrsvalid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsdsetattr() is skipped, and the POSIX ACL is never applied to the inode.

Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.(CVE-2025-68803)

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

io_uring: fix filename leak in __ioopenatprep()

__ioopenatprep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having OCLOEXEC flag set, the function returns early. At that point, the request doesn't have REQFNEEDCLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak.

Fix this by setting the REQFNEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup.(CVE-2025-68814)

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

net/mlx5: fw_tracer, Validate format string parameters

Add validation for format string parameters in the firmware tracer to prevent potential security vulnerabilities and crashes from malformed format strings received from firmware.

The firmware tracer receives format strings from the device firmware and uses them to format trace messages. Without proper validation, bad firmware could provide format strings with invalid format specifiers (e.g., %s, %p, %n) that could lead to crashes, or other undefined behavior.

Add mlx5tracervalidateparams() to validate that all format specifiers in trace strings are limited to safe integer/hex formats (%x, %d, %i, %u, %llx, %lx, etc.). Reject strings containing other format types that could be used to access arbitrary memory or cause crashes. Invalid format strings are added to the trace output for visibility with "BADFORMAT: " prefix.(CVE-2025-68816)

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

scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"

This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.

The commit being reverted added code to _qla2x00abortallcmds() to call sp->done() without holding a spinlock. But unlike the older code below it, this new code failed to check sp->cmdtype and just assumed TYPESRB, which results in a jump to an invalid pointer in target-mode with TYPETGTCMD:

qla2xxx [0000:65:00.0]-d034:8: qla24xxdonackwork create sess success 0000000009f7a79b qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h. qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no buffer qla2xxx [0000:65:00.0]-f03a:8: qlatarget(0): System error async event 0x8002 occurred qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda. BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor instruction fetch in kernel mode PF: errorcode(0x0010) - not-present page PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9446 Comm: qla2xxx8_dpc Tainted: G O 6.1.133 #1 Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206 RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000 RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0 RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045 R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40 R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400 FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x4d/0x8b ? pagefaultoops+0x91/0x180 ? tracebufferunlockcommitregs+0x38/0x1a0 ? excpagefault+0x391/0x5e0 ? asmexcpage_fault+0x22/0x30 __qla2x00abortallcmds+0xcb/0x3e0 [qla2xxxscst] qla2x00abortallcmds+0x50/0x70 [qla2xxxscst] qla2x00abortispcleanup+0x3b7/0x4b0 [qla2xxxscst] qla2x00abortisp+0xfd/0x860 [qla2xxxscst] qla2x00dodpc+0x581/0xa40 [qla2xxxscst] kthread+0xa8/0xd0 </TASK>

Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early within lock") added the spinlock back, because not having the lock caused a race and a crash. But qla2x00abortsrb() in the switch below already checks for qla2x00chipis_down() and handles it the same way, so the code above the switch is now redundant and still buggy in target-mode. Remove it.(CVE-2025-68818)

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

shmem: fix recovery on rename failures

mapletree insertions can fail if we are seriously short on memory; simpleoffsetrename() does not recover well if it runs into that. The same goes for simpleoffsetrenameexchange().

Moreover, shmemwhiteout() expects that if it succeeds, the caller will progress to dmove(), i.e. that shmemrename2() won't fail past the successful call of shmemwhiteout().

Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton.

For simpleoffsetrename_exchange() that's enough - we just need to be careful about the order of operations.

For simpleoffsetrename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations.

That preinsertion has to be done in shmemrename2() rather than in simpleoffsetrename() itself - otherwise we'd need to deal with the possibility of failure after successful shmemwhiteout().(CVE-2025-71072)

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

KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer

When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in updatetargetexpiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.

Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.

More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpupreemptiontimer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).

After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.

E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).

NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advanceperiodictargetexpiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apictimer_fn+0x31/0x50 [kvm] __hrtimerrunqueues+0x100/0x280 hrtimerinterrupt+0x100/0x210 ? ttwudowakeup+0x19/0x160 smpapictimerinterrupt+0x6a/0x130 apictimerinterrupt+0xf/0x20 </IRQ>

Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---(CVE-2025-71104)

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

libceph: make decode_pool() more resilient against corrupted osdmaps

If the osdmap is (maliciously) corrupted such that the encoded length of cephpgpool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.

This patch adds explicit bounds checks for each field that is decoded or skipped.(CVE-2025-71116)

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

crypto: seqiv - Do not use req->iv after cryptoaeadencrypt

As soon as cryptoaeadencrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.

Instead of checking req->iv against info, create a new variable unaligned_info and use it for that purpose instead.(CVE-2025-71131)

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

KEYS: trusted: Fix a memory leak in tpm2loadcmd

'tpm2loadcmd' allocates a tempoary blob indirectly via 'tpm2keydecode' but it is not freed in the failure paths. Address this by wrapping the blob into with a cleanup helper.(CVE-2025-71147)

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

iouring/poll: correctly handle iopoll_add() return value on update

When the core of iouring was updated to handle completions consistently and with fixed return codes, the POLLREMOVE opcode with updates got slightly broken. If a POLLADD is pending and then POLLREMOVE is used to update the events of that request, if that update causes the POLL_ADD to now trigger, then that completion is lost and a CQE is never posted.

Additionally, ensure that if an update does cause an existing POLLADD to complete, that the completion value isn't always overwritten with -ECANCELED. For that case, whatever iopoll_add() set the value to should just be retained.(CVE-2025-71149)

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

ksmbd: Fix refcount leak when invalid session is found on session lookup

When a session is found but its state is not SMB2SESSIONVALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbdusersession_put to release the reference to the session.(CVE-2025-71150)

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

net/mlx5e: Don't store mlx5epriv in mlx5edev devlink priv

mlx5epriv is an unstable structure that can be memset(0) if profile attaching fails, mlx5epriv in mlx5edev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5edev and get mdev from the containing mlx5_adev aux device structure.

This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.

$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchange_profile: failed to rollback to orig profile, -12

$ devlink dev reload pci/0000:00:03.0 ==> oops

BUG: kernel NULL pointer dereference, address: 0000000000000520 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5eremove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: <TASK> devicereleasedriverinternal+0x19c/0x200 busremovedevice+0xc6/0x130 devicedel+0x160/0x3d0 ? devlparamdriverinitvalueget+0x2d/0x90 mlx5detachdevice+0x89/0xe0 mlx5unloadonedevllocked+0x3a/0x70 mlx5devlinkreloaddown+0xc8/0x220 devlinkreload+0x7d/0x260 devlinknlreloaddoit+0x45b/0x5a0 genlfamilyrcvmsg_doit+0xe8/0x140(CVE-2026-22996)

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:

net/mlx5e: Fix crash on profile change rollback failure

mlx5enetdevchangeprofile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdevpriv. A retry to change profile, e.g. another attempt to call mlx5enetdevchange_profile via switchdev mode change, will crash trying to access the now NULL priv->mdev.

This fix allows mlx5enetdevchange_profile() to handle previous failures and an empty priv, by not assuming priv is valid.

Pass netdev and mdev to all flows requiring mlx5enetdevchangeprofile() and avoid passing priv. In mlx5enetdevchangeprofile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one.

This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure:

## Enabling switchdev mode first time:

mlx5core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12 ^^^^^^^^ mlx5core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)

## retry: Enabling switchdev mode 2nd time:

mlx5core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5edetachnetdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5enetdevchangeprofile+0x45/0xb0 mlx5evportrepload+0x27b/0x2d0 mlx5eswoffloadsrepload+0x72/0xf0 eswoffloadsenable+0x5d0/0x970 mlx5eswitchenablelocked+0x349/0x430 ? ismpsupported+0x57/0xb0 mlx5devlinkeswitchmodeset+0x26b/0x430 devlinknleswitchsetdoit+0x6f/0xf0 genlfamilyrcvmsgdoit+0xe8/0x140 genlrcv_msg+0x18b/0x290 ? __pfxdevlinknlpredoit+0x10/0x10 ? __pfxdevlinknl_eswitchsetdoit+0x10/0x10 ? __pfxdevlinknlpostdoit+0x10/0x10 ? __pfxgenlrcvmsg+0x10/0x10 netlinkrcvskb+0x52/0x100 genlrcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __allocskb+0xd6/0x190 netlinksendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64syssendto+0x24/0x30 dosyscall64+0x50/0x1f0 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047(CVE-2026-23000)

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

x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1

When loading guest XSAVE state via KVMSETXSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATEBV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATEBV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel.

E.g. if fpuupdateguestxfd() sets XFD without clearing XSTATEBV:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#29: amxtest/848 Modules linked in: kvmintel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amxtest Not tainted 6.19.0-rc2-ffa07f7fd437-x86amxnmxfdnoninit-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 switchfpureturn+0x4a/0xb0 kvmarchvcpuioctlrun+0x1245/0x1e40 [kvm] kvmvcpu_ioctl+0x2c3/0x8f0 [kvm] __x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

This can happen if the guest executes WRMSR(MSRIA32XFD) to set XFD[18] = 1, and a host IRQ triggers kernelfpubegin() prior to the vmexit handler's call to fpuupdateguest_xfd().

and if userspace stuffs XSTATEBV[i]=1 via KVMSET_XSAVE:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#14: amxtest/867 Modules linked in: kvmintel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amxtest Not tainted 6.19.0-rc2-2dace9faccd6-x86amxnmxfdnoninit-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 fpuswapkvmfpstate+0x6b/0x120 kvmloadguestfpu+0x30/0x80 [kvm] kvmarchvcpuioctlrun+0x85/0x1e40 [kvm] kvmvcpu_ioctl+0x2c3/0x8f0 [kvm] __x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component):

If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATEBV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).

Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpuguest. However, having XSTATEBV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpuswapkvmfpstate()'s call to savefpregstofpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD.

Therefore, XFD can only go out of sync with XSTATEBV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVMGETXSAVE returns XSTATEBV[i]=0 for XFD-disabled features.

[Move clea ---truncated---(CVE-2026-23005)

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

net/mlx5e: Pass netdev to mlx5edestroynetdev instead of priv

mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails.

Pass netdev to mlx5edestroynetdev() to guarantee it will work on a valid netdev.

On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there.

This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.

$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchangeprofile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5core 0012:03:00.1: mlx5enetdevinitprofile:6214:(pid 37199): mlx5eprivinit failed, err=-12 mlx5core 0012:03:00.1 gpu3rdma1: mlx5enetdevchange_profile: failed to rollback to orig profile, -12

$ devlink dev reload pci/0000:00:03.0 ==> oops

BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5edcbnldscpapp+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace: <TASK> mlx5eremove+0x57/0x110 devicereleasedriverinternal+0x19c/0x200 busremovedevice+0xc6/0x130 devicedel+0x160/0x3d0 ? devlparamdriverinitvalueget+0x2d/0x90 mlx5detachdevice+0x89/0xe0 mlx5unloadonedevllocked+0x3a/0x70 mlx5devlinkreloaddown+0xc8/0x220 devlinkreload+0x7d/0x260 devlinknlreloaddoit+0x45b/0x5a0 genlfamilyrcvmsg_doit+0xe8/0x140(CVE-2026-23035)

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

tracing: Add recursion protection in kernel stack trace recording

A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.

Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).

Have the stack trace code use the interrupt context to protect against recursion.

Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.(CVE-2026-23138)