OESA-2026-1760

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:

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 &lt; 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-&gt;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)

[ 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

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:
 &lt;TASK&gt;
 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-&gt;pmu)-&gt;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 &quot;ftp_helper&quot;
    }

} 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:

timers: Fix NULL function pointer race in timershutdownsync()

There is a race condition between timershutdownsync() and timer expiration that can lead to hitting a WARNON in expiretimers().

The issue occurs when timershutdownsync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:

CPU0 CPU1 <SOFTIRQ> locktimerbase() expiretimers() base->runningtimer = timer; unlocktimerbase() [calltimerfn enter] modtimer() ... timershutdownsync() locktimerbase() // For now, will not detach the timer but only clear its function to NULL if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase() [calltimerfn exit] locktimerbase() base->runningtimer = NULL; unlocktimerbase() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expiretimers() WARNONONCE(!fn) // hit ... locktimerbase() // Now timer will detach if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimer_base()

The problem is that timershutdownsync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARNONONCE(!fn) check in expire_timers().

Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.(CVE-2025-68214)

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:

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, &amp;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:

Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.
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:

ksmbd: fix use-after-free in ksmbdtreeconnect_put under concurrency

Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.(CVE-2025-68817)

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:

tpm: Cap the number of PCR banks

tpm2getpcr_allocation() does not cap any upper limit for the number of banks. Cap the limit to eight banks so that out of bounds values coming from external I/O cause on only limited harm.(CVE-2025-71077)

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:

mm/page_alloc: change all pageblocks migrate type on coalescing

When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed.

However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged.

That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced.

[ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/pagealloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algifhash(E) afalg(E) nftfibinet(E) nftfibipv4(E) nftfibipv6(E) nftfib(E) nftrejectinet(E) nfrejectipv4(E) nfrejectipv6(E) nftreject(E) nftct(E) nftchainnat(E) nfnat(E) nfconntrack(E) nfdefragipv6(E) nfdefragipv4(E) nftables(E) s390trng(E) vfioccw(E) mdev(E) vfioiommutype1(E) vfio(E) schfqcodel(E) drm(E) i2ccore(E) drmpanelorientationquirks(E) loop(E) nfnetlink(E) vsockloopback(E) vmwvsockvirtiotransportcommon(E) vsock(E) ctcm(E) fsm(E) diag288wdt(E) watchdog(E) zfcp(E) scsitransportfc(E) ghashs390(E) prng(E) aess390(E) desgeneric(E) dess390(E) libdes(E) sha3512s390(E) sha3256s390(E) shacommon(E) paess390(E) cryptoengine(E) pkeycca(E) pkeyep11(E) zcrypt(E) rngcore(E) pkeypckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmacs390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempigverify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNEDMODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60 #00000349976fa5fc: af000000 mc 0,0 >00000349976fa600: a7f4ff4c brc 15,00000349976fa498 00000349976fa604: b9040026 lgr %r2,%r6 00000349976fa608: c0300088317f larl %r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0 00000349976fa614: af000000 mc 0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueuebulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueuepcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] getpagefromfreelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __allocfrozenpagesnoprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] allocpagesmpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folioallocmpolnoprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vmaallocfolionoprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vmaallocanonfolio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __dohugepmdanonymouspage+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---(CVE-2025-71134)

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: dsa: properly keep track of conduit reference

Problem description

DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.

There are two distinct problems.

The OF path, which uses offindnetdevicebynode(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsadevtonetdevice() has a putdevice() call which is missing in dsaportparseof(), but we can actually even verify that an issue exists. With CONFIGDEBUGKOBJECTRELEASE=y, if we run this command "before" and "after" applying this patch:

(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind

we see these lines in the output diff which appear only with the patch applied:

kobject: 'eno2' (ffff002009a3a6b8): kobjectrelease, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobjectrelease, parent 0000000000000000 (delayed 1000)

After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpudp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (devhold() and dev_put()).

Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdevupperdevlink(). But time still passes at DSA switch probe time between the initial offindnetdevicebynode() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.

So we have to run offindnetdevicebynode() under rtnllock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.

Do we need to keep the reference until dsaunregisterswitch() / dsaswitchshutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpudp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsatreefindfirst_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.

As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.

History and blame attribution

The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.

We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---(CVE-2025-71152)

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

net: usb: rtl8150: fix memory leak on usbsubmiturb() failure

In asyncsetregisters(), when usbsubmiturb() fails, the allocated async_req structure and URB are not freed, causing a memory leak.

The completion callback asyncsetreg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.

Fix this by freeing both the URB and the request structure in the error path when usbsubmiturb() fails.(CVE-2025-71154)

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

scsi: qla2xxx: Fix bsg_done() causing double free

Kernel panic observed on system,

[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: errorcode(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el95.x8664 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpyerms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] <TASK> [5353358.825224] ? showtraceloglvl+0x1c4/0x2df [5353358.825229] ? showtraceloglvl+0x1c4/0x2df [5353358.825232] ? sgcopybuffer+0xc8/0x110 [5353358.825236] ? _diebody.cold+0x8/0xd [5353358.825238] ? pagefaultoops+0x134/0x170 [5353358.825242] ? kernelmodefixuporoops+0x84/0x110 [5353358.825244] ? excpagefault+0xa8/0x150 [5353358.825247] ? asmexcpagefault+0x22/0x30 [5353358.825252] ? memcpyerms+0x6/0x10 [5353358.825253] sgcopybuffer+0xc8/0x110 [5353358.825259] qla2x00processvendorspecific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xxbsgrequest+0x1b2/0x2d0 [qla2xxx]

Most routines in qlabsg.c call bsgdone() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().(CVE-2025-71238)

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

wifi: avoid kernel-infoleak from struct iw_point

struct iw_point has a 32bit hole on 64bit arches.

struct iw_point { void __user pointer; / Pointer to the data (in user space) / __u16 length; / number of fields or size in bytes / __u16 flags; / Optional params */ };

Make sure to zero the structure to avoid disclosing 32bits of kernel data to user space.(CVE-2026-22978)

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4end_grace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4end_grace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceend_forced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.(CVE-2026-22980)

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

libceph: replace overzealous BUGON in osdmapapply_incremental()

If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.(CVE-2026-22990)

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

libceph: return the handler error from monhandleauth_done()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauth_signature().(CVE-2026-22992)

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 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:

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).

Add a minimum AAD length check to fail fast on invalid inputs.(CVE-2026-23060)

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

vsock/virtio: fix potential underflow in virtiotransportget_credit()

The credit calculation in virtiotransportget_credit() uses unsigned arithmetic:

ret = vvs->peerbufalloc - (vvs->txcnt - vvs->peerfwd_cnt);

If the peer shrinks its advertised buffer (peerbufalloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle.

Reuse virtiotransporthas_space() which already handles this case and add a comment to make it clear why we are doing that.

[Stefano: use virtiotransporthas_space() instead of duplicating the code] Stefano: tweak the commit message

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

regmap: Fix race condition in hwspinlock irqsave routine

Previously, the address of the shared member '&map->spinlockflags' was passed directly to 'hwspinlocktimeoutirqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner.

Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.(CVE-2026-23071)

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

vsock/virtio: cap TX credit to local buffer size

The virtio transports derives its TX credit directly from peerbufalloc, which is set from the remote endpoint's SOVMSOCKETSBUFFERSIZE value.

On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base.

Introduce a small helper, virtiotransporttxbufsize(), that returns min(peerbufalloc, bufalloc), and use it wherever we consume peerbuf_alloc.

This ensures the effective TX window is bounded by both the peer's advertised buffer and our own bufalloc (already clamped to buffermaxsize via SOVMSOCKETSBUFFERMAXSIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings.

On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited.

With this patch applied:

Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB

After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB

Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive.

Compatibility with non-virtio transports:

VMCI uses the AFVSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer* values; the remote side cannot enlarge those queues beyond what the local endpoint configured.
Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peerbufalloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes.
The loopback path reuses virtiotransportcommon.c, so it naturally follows the same semantics as the virtio transport.

This change is limited to virtiotransportcommon.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have.

[Stefano: small adjustments after changing the previous patch] Stefano: tweak the commit message

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

bonding: limit BONDMODE8023AD to Ethernet devices

BONDMODE8023AD makes sense for ARPHRD_ETHER only.

syzbot reported:

BUG: KASAN: global-out-of-bounds in __hwaddrcreate net/core/devaddrlists.c:63 [inline] BUG: KASAN: global-out-of-bounds in _hwaddraddex+0x25d/0x760 net/core/devaddrlists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497

CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstacklvl+0xe8/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:-1 [inline] kasancheck_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hwaddrcreate net/core/devaddrlists.c:63 [inline] __hwaddraddex+0x25d/0x760 net/core/devaddr_lists.c:118 __devmcadd net/core/devaddrlists.c:868 [inline] devmcadd+0xa1/0x120 net/core/devaddrlists.c:886 bondenslave+0x2b8b/0x3ac0 drivers/net/bonding/bondmain.c:2180 dosetmaster+0x533/0x6d0 net/core/rtnetlink.c:2963 dosetlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnlchangelink net/core/rtnetlink.c:3776 [inline] __rtnlnewlink net/core/rtnetlink.c:3935 [inline] rtnlnewlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlinkrcvmsg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlinkrcvskb+0x208/0x470 net/netlink/afnetlink.c:2550 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x82f/0x9e0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x805/0xb30 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __syssendmsg+0x164/0x220 net/socket.c:2678 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] __dofastsyscall32+0x1dc/0x560 arch/x86/entry/syscall32.c:307 dofastsyscall32+0x34/0x80 arch/x86/entry/syscall32.c:332 entrySYSENTERcompatafterhwframe+0x84/0x8e </TASK>

The buggy address belongs to the variable: lacpdumcastaddr+0x0/0x40(CVE-2026-23099)

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

ipvlan: Make the addrs_lock be per port

Make the addrs_lock be per port, not per ipvlan dev.

Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So

1) Introduce per-port addrs_lock.

2) It was needed to fix places where it was forgotten to take lock (ipvlanopen/ipvlanclose)

This appears to be a very minor problem though. Since it's highly unlikely that ipvlanaddaddr() will be called on 2 CPU simultaneously. But nevertheless, this could cause:

1) False-negative of ipvlanaddrbusy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlanaddr6event() can be called without rtnl_lock.

2) Race since ipvlanhtaddradd(port) is called under different ipvlan->addrslock locks

This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.(CVE-2026-23103)

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

net/sched: qfq: Use clisactive to determine whether class is active in qfqrmfrom_ag

This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use clisactive instead of relying on the child qdisc's qlen to determine class activation.(CVE-2026-23105)

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

netfilter: nftables: fix inverted genmask check in nftmapcatchallactivate()

nftmapcatchallactivate() has an inverted element activity check compared to its non-catchall counterpart nftmapelem_activate() and compared to what is logically required.

nftmapcatchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.

Compare the non-catchall activate callback, which is correct:

nftmapelemactivate(): if (nftsetelem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */

With the buggy catchall version:

nftmapcatchallactivate(): if (!nftsetelemactive(ext, genmask)) continue; /* skip inactive, process active */

The consequence is that when a DELSET operation is aborted, nftsetelemdataactivate() is never called for the catchall element. For NFTGOTO verdict elements, this means nftdatahold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.

This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIGUSERNS and CONFIGNFTABLES.

Fix by removing the negation so the check matches nftmapelemactivate(): skip active elements, process inactive ones.(CVE-2026-23111)

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

l2tp: avoid one data-race in l2tptunneldel_work()

We should read sk->sk_socket only when dealing with kernel sockets.

syzbot reported the following data-race:

BUG: KCSAN: data-race in l2tptunneldelwork / skcommon_release

write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sksetsocket include/net/sock.h:2092 [inline] sockorphan include/net/sock.h:2118 [inline] skcommonrelease+0xae/0x230 net/core/sock.c:4003 udplibclose+0x15/0x20 include/net/udp.h:325 inetrelease+0xce/0xf0 net/ipv4/af_inet.c:437 __sockrelease net/socket.c:662 [inline] sockclose+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/filetable.c:496 taskworkrun+0x131/0x1a0 kernel/taskwork.c:233 resumeusermode_work include/linux/resumeusermode.h:50 [inline] __exittousermodeloop kernel/entry/common.c:44 [inline] exittousermodeloop+0x1fe/0x740 kernel/entry/common.c:75 _exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x1e1/0x2b0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tptunneldelwork+0x2f/0x1a0 net/l2tp/l2tpcore.c:1418 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0x4ce/0x9d0 kernel/workqueue.c:3340 workerthread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 retfromfork+0x149/0x290 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:246

value changed: 0xffff88811b818000 -> 0x0000000000000000(CVE-2026-23120)

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

ipv6: annotate data-race in ndiscrouterdiscovery()

syzbot found that ndiscrouterdiscovery() could read and write in6dev->ramtu without holding a lock [1]

This looks fine, IFLAINET6RA_MTU is best effort.

Add READONCE()/WRITEONCE() to document the race.

Note that we might also reject illegal MTU values (mtu < IPV6MINMTU || mtu > skb->dev->mtu) in a future patch.

[1] BUG: KCSAN: data-race in ndiscrouterdiscovery / ndiscrouterdiscovery

read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndiscrouterdiscovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndiscrcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6protocoldeliverrcu+0xb2a/0x10d0 net/ipv6/ip6input.c:438 ip6inputfinish+0xf0/0x1d0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x5e/0x140 net/ipv6/ip6input.c:500 ip6mcinput+0x27c/0x470 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x336/0x340 net/ipv6/ip6_input.c:79 ...

write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndiscrouterdiscovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndiscrcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6protocoldeliverrcu+0xb2a/0x10d0 net/ipv6/ip6input.c:438 ip6inputfinish+0xf0/0x1d0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x5e/0x140 net/ipv6/ip6input.c:500 ip6mcinput+0x27c/0x470 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x336/0x340 net/ipv6/ip6_input.c:79 ...

value changed: 0x00000000 -> 0xe5400659(CVE-2026-23124)

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

netdevsim: fix a race issue related to the operation on bpfboundprogs list

The netdevsim driver lacks a protection mechanism for operations on the bpfboundprogs list. When the nsimbpfcreateprog() performs listaddtail, it is possible that nsimbpfdestroyprog() is simultaneously performs list_del. Concurrent operations on the list may lead to list corruption and trigger a kernel crash as follows:

[ 417.290971] kernel BUG at lib/listdebug.c:62! [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 417.291007] Workqueue: events bpfprogfreedeferred [ 417.291021] RIP: 0010:__listdelentryvalidorreport+0xa7/0xc0 [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246 [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000 [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180 [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003 [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20 [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000 [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0 [ 417.291088] PKRU: 55555554 [ 417.291091] Call Trace: [ 417.291096] <TASK> [ 417.291103] nsimbpfdestroyprog+0x31/0x80 [netdevsim] [ 417.291154] __bpfprogoffloaddestroy+0x2a/0x80 [ 417.291163] bpfprogdevbounddestroy+0x6f/0xb0 [ 417.291171] bpfprogfreedeferred+0x18e/0x1a0 [ 417.291178] processonework+0x18a/0x3a0 [ 417.291188] worker_thread+0x27b/0x3a0 [ 417.291197] ? __pfxworkerthread+0x10/0x10 [ 417.291207] kthread+0xe5/0x120 [ 417.291214] ? __pfxkthread+0x10/0x10 [ 417.291221] retfrom_fork+0x31/0x50 [ 417.291230] ? __pfxkthread+0x10/0x10 [ 417.291236] retfromforkasm+0x1a/0x30 [ 417.291246] </TASK>

Add a mutex lock, to prevent simultaneous addition and deletion operations on the list.(CVE-2026-23126)

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

wifi: ath10k: fix dmafreecoherent() pointer

dmaalloccoherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.(CVE-2026-23133)

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

libceph: reset sparse-read state in osd_fault()

When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state.

If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like:

libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read

Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state.(CVE-2026-23136)

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

of: unittest: Fix memory leak in unittestdataadd()

In unittestdataadd(), if ofresolvephandles() fails, the allocated unittest_data is not freed, leading to a memory leak.

Fix this by using scope-based cleanup helper _free(kfree) for automatic resource cleanup. This ensures unittestdata is automatically freed when it goes out of scope in error paths.

For the success path, use retainandnull_ptr() to transfer ownership of the memory to the device tree and prevent double freeing.(CVE-2026-23137)

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)

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

netfilter: nfconncount: update lastgc only when GC has been performed

Currently last_gc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely.

Update the last_gc value only when a GC has been actually performed.(CVE-2026-23139)

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

ext4: fix iloc.bh leak in ext4xattrinodeupdateref

The error branch for ext4xattrinodeupdateref forget to release the refcount for iloc.bh. Find this when review code.(CVE-2026-23145)

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

net: fix segmentation of forwarding fraglist GRO

This patch enhances GSO segment handling by properly checking the SKBGSODODGY flag for frag_list GSO packets, addressing low throughput issues observed when a station accesses IPv4 servers via hotspots with an IPv6-only upstream interface.

Specifically, it fixes a bug in GSO segmentation when forwarding GRO packets containing a fraglist. The function skbsegmentlist cannot correctly process GRO skbs that have been converted by XLAT, since XLAT only translates the header of the head skb. Consequently, skbs in the fraglist may remain untranslated, resulting in protocol inconsistencies and reduced throughput.

To address this, the patch explicitly sets the SKBGSODODGY flag for GSO packets in XLAT's IPv4/IPv6 protocol translation helpers (bpfskbproto4to6 and bpfskbproto6to4). This marks GSO packets as potentially modified after protocol translation. As a result, GSO segmentation will avoid using skbsegmentlist and instead falls back to skbsegment for packets with the SKBGSODODGY flag. This ensures that only safe and fully translated fraglist packets are processed by skbsegmentlist, resolving protocol inconsistencies and improving throughput when forwarding GRO packets converted by XLAT.(CVE-2026-23154)

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

efivarfs: fix error propagation in efivarentryget()

efivarentryget() always returns success even if the underlying __efivarentryget() fails, masking errors.

This may result in uninitialized heap memory being copied to userspace in the efivarfsfileread() path.

Fix it by returning the error from __efivarentryget().(CVE-2026-23156)

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

mptcp: fix race in mptcppmnlflushaddrs_doit()

syzbot and Eulgyu Kim reported crashes in mptcppmnlgetlocalid() and/or mptcppmnlis_backup()

Root cause is listspliceinit() in mptcppmnlflushaddrs_doit() which is not RCU ready.

listspliceinit_rcu() can not be called here while holding pernet->lock spinlock.

Many thanks to Eulgyu Kim for providing a repro and testing our patches.(CVE-2026-23169)

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

net/mlx5e: TC, delete flows only for existing peers

When deleting TC steering flows, iterate only over actual devcom peers instead of assuming all possible ports exist. This avoids touching non-existent peers and ensures cleanup is limited to devices the driver is currently connected to.

BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5etcdelfdbpeersflow+0xbe/0x200 [mlx5core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5etcdelflow+0x46/0x270 [mlx5core] mlx5eflowput+0x25/0x50 [mlx5core] mlx5edeleteflower+0x2a6/0x3e0 [mlx5core] tcsetupcbreoffload+0x20/0x80 flreoffload+0x26f/0x2f0 [clsflower] ? mlx5etcreoffloadflowswork+0xc0/0xc0 [mlx5core] ? mlx5etcreoffloadflowswork+0xc0/0xc0 [mlx5core] tcfblockplaybackoffloads+0x9e/0x1c0 tcfblockunbind+0x7b/0xd0 tcfblocksetup+0x186/0x1d0 tcfblockoffloadcmd.isra.0+0xef/0x130 tcfblockoffload_unbind+0x43/0x70 __tcfblockput+0x85/0x160 ingressdestroy+0x32/0x110 [schingress] __qdiscdestroy+0x44/0x100 qdiscgraft+0x22b/0x610 tcgetqdisc+0x183/0x4d0 rtnetlinkrcvmsg+0x2d7/0x3d0 ? rtnlcalcit.isra.0+0x100/0x100 netlinkrcvskb+0x53/0x100 netlinkunicast+0x249/0x320 ? __allocskb+0x102/0x1f0 netlinksendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 ____syssendmsg+0x1ef/0x230 ? copymsghdrfromuser+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ? __sys_sendto+0x119/0x180 __syssendmsg+0x61/0xb0 dosyscall64+0x55/0x640 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780(CVE-2026-23173)

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

ALSA: aloop: Fix racy access at PCM trigger

The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.

For addressing the UAF, this patch changes two things: - It covers the most of code in loopbackcheckformat() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.(CVE-2026-23191)

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

KVM: Don't clobber irqfd routing type when deassigning irqfd

When deassigning a KVMIRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvmarchirqbypassdelproducer() on x86 and arm64, which explicitly look for KVMIRQROUTINGMSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvmarchupdateirqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone.

As a bonus, checking that the irqfd is active provides a convenient location for documenting why KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens before the eventfd is detached), it will no longer receive updates via kvmirqroutingupdate(), and so KVM could deliver an event using stale routing information (relative to KVMSETGSIROUTING returning to userspace).

As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvmirqroutingupdate() won't invoke kvmarchupdateirqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information.

As for kvmarchirqbypassdel_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd.

Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amdiommuupdatega() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irqbypassdata being NULL when read by avicupdateiommuvcpu_affinity():

BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfioirqtest Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amdiommuupdatega+0x19/0xe0 Call Trace: <TASK> avicupdateiommuvcpuaffinity+0x3d/0x90 [kvmamd] __avicvcpuload+0xf4/0x130 [kvm_amd] kvmarchvcpuload+0x89/0x210 [kvm] vcpuload+0x30/0x40 [kvm] kvmarchvcpuioctlrun+0x45/0x620 [kvm] kvmvcpuioctl+0x571/0x6a0 [kvm] __sesysioctl+0x6d/0xb0 dosyscall64+0x6f/0x9d0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x46893b </TASK> ---[ end trace 0000000000000000 ]---

If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment.

listadd corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfioirqtest Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:listaddvalidorreport+0x97/0xc0 Call Trace: <TASK> avicpiupdateirte+0x28e/0x2b0 [kvmamd] kvmpiupdateirte+0xbf/0x190 [kvm] kvmarchirqbypassaddproducer+0x72/0x90 [kvm] irqbypassregisterconsumer+0xcd/0x170 [irqbypa ---truncated---(CVE-2026-23198)

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointer_careful() instead.

GangMin Kim provided a report and a repro fooling u32_classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221(CVE-2026-23204)

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

ALSA: usb-audio: Prevent excessive number of frames

In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].

Added a check for the number of single data URB frames when calculating the number of frames to prevent [1].

[1] BUG: KASAN: slab-out-of-bounds in copytourb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copytourb+0x261/0x460 sound/usb/pcm.c:1487 prepareplaybackurb+0x953/0x13d0 sound/usb/pcm.c:1611 prepareoutboundurb+0x377/0xc50 sound/usb/endpoint.c:333(CVE-2026-23208)

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

bonding: annotate data-races around slave->last_rx

slave->lastrx and slave->targetlastarprx[...] can be read and written locklessly. Add READONCE() and WRITEONCE() annotations.

syzbot reported:

BUG: KCSAN: data-race in bondrcvvalidate / bondrcvvalidate

write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bondrcvvalidate+0x202/0x7a0 drivers/net/bonding/bondmain.c:3335 bondhandleframe+0xde/0x5e0 drivers/net/bonding/bondmain.c:1533 __netifreceiveskb_core+0x5b1/0x1950 net/core/dev.c:6039 __netifreceiveskbonecore net/core/dev.c:6150 [inline] _netifreceiveskb+0x59/0x270 net/core/dev.c:6265 netifreceiveskbinternal net/core/dev.c:6351 [inline] netifreceiveskb+0x4b/0x2d0 net/core/dev.c:6410 ...

write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bondrcvvalidate+0x202/0x7a0 drivers/net/bonding/bondmain.c:3335 bondhandleframe+0xde/0x5e0 drivers/net/bonding/bondmain.c:1533 __netifreceiveskb_core+0x5b1/0x1950 net/core/dev.c:6039 __netifreceiveskbonecore net/core/dev.c:6150 [inline] __netifreceiveskb+0x59/0x270 net/core/dev.c:6265 netifreceiveskbinternal net/core/dev.c:6351 [inline] netifreceiveskb+0x4b/0x2d0 net/core/dev.c:6410 brnetifreceiveskb net/bridge/brinput.c:30 [inline] NFHOOK include/linux/netfilter.h:318 [inline] ...

value changed: 0x0000000100005365 -> 0x0000000100005366(CVE-2026-23212)

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

bus: fsl-mc: fix use-after-free in driveroverrideshow()

The driveroverrideshow() function reads the driveroverride string without holding the devicelock. However, driveroverridestore() uses driversetoverride(), which modifies and frees the string while holding the device_lock.

This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function.

Fix this by holding the device_lock around the read operation.(CVE-2026-23221)

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

smb: client: split cached_fid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x86_64), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.(CVE-2026-23230)

Database specific

{
    "severity": "High"
}

References

Affected packages

openEuler:24.03-LTS-SP1 / kernel

Package

Name: kernel
Purl: pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0Unknown introduced version / All previous versions are affected

Fixed

6.6.0-144.0.0.139.oe2403sp1

Ecosystem specific

{
    "x86_64": [
        "bpftool-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "bpftool-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-debugsource-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-devel-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-headers-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-source-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-tools-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-tools-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "kernel-tools-devel-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "perf-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "python3-perf-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm",
        "python3-perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.x86_64.rpm"
    ],
    "aarch64": [
        "bpftool-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "bpftool-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-debugsource-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-devel-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-headers-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-source-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-tools-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-tools-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "kernel-tools-devel-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "perf-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "python3-perf-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm",
        "python3-perf-debuginfo-6.6.0-144.0.0.139.oe2403sp1.aarch64.rpm"
    ],
    "src": [
        "kernel-6.6.0-144.0.0.139.oe2403sp1.src.rpm"
    ]
}

Database specific

source

"https://repo.openeuler.org/security/data/osv/OESA-2026-1760.json"