OESA-2026-1303

WARNING: CPU: 1 PID: 9150 at net/core/pagepool.c:709 pagepoolputpage net/core/pagepool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/pagepool.c:709 pagepoolputunrefednetmem+0x157/0xa40 net/core/pagepool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:pagepoolputpage net/core/pagepool.c:709 [inline] RIP: 0010:pagepoolputunrefednetmem+0x157/0xa40 net/core/pagepool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tunptrfree drivers/net/tun.c:617 [inline] _ptrringswapqueue include/linux/ptrring.h:571 [inline] ptrringresizemultiplenoprof include/linux/ptrring.h:643 [inline] tunqueueresize drivers/net/tun.c:3694 [inline] tundeviceevent+0xaaf/0x1080 drivers/net/tun.c:3714 notifiercallchain+0x19f/0x3e0 kernel/notifier.c:93 callnetdevicenotifiersextack net/core/dev.c:2032 [inline] callnetdevicenotifiers net/core/dev.c:2046 [inline] devchangetxqueuelen+0x158/0x2a0 net/core/dev.c:9024 dosetlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnlsetlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlinkrcvmsg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2550(CVE-2024-57994)

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

ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params

Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.(CVE-2024-58012)

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

driver core: fix potential NULL pointer dereference in dev_uevent()

If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it.

Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.(CVE-2025-37800)

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

net/mdiobus: Fix potential out-of-bounds clause 45 read/write access

When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHYMAXADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.

Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38110)

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

net/mdiobus: Fix potential out-of-bounds read/write access

When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHYMAXADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.

Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)

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

net: phy: clear phydev->devlink when the link is deleted

There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phydetach() calls devicelinkdel() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phyattachdirect() fails before calling devicelinkadd(), the code jumps to the "error" label and calls phydetach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, devicelinkdel() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows.

[ 24.702421] Call trace: [ 24.704856] devicelinkputkref+0x20/0x120 [ 24.709124] devicelinkdel+0x30/0x48 [ 24.712864] phydetach+0x24/0x168 [ 24.716261] phyattachdirect+0x168/0x3a4 [ 24.720352] phylinkfwnodephyconnect+0xc8/0x14c [ 24.725140] phylinkofphyconnect+0x1c/0x34

Therefore, phydev->devlink needs to be cleared when the device link is deleted.(CVE-2025-38149)

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

netfilter: nftsetpipapo: prevent overflow in lookup table allocation

When calculating the lookup table size, ensure the following multiplication does not overflow:

desc->fieldlen[] maximum value is U8MAX multiplied by NFTPIPAPOGROUPSPERBYTE(f) that can be 2, worst case.
NFTPIPAPOBUCKETS(f->bb) is 2^8, worst case.
sizeof(unsigned long), from sizeof(*f->lt), lt in struct nftpipapofield.

Then, use checkmuloverflow() to multiply by bucket size and then use checkaddoverflow() to the alignment for avx2 (if needed). Finally, add ltsizecheck_overflow() helper and use it to consolidate this.

While at it, replace leftover allocation using the GFPKERNEL to GFPKERNELACCOUNT for consistency, in pipaporesize().(CVE-2025-38162)

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

smb: client: add NULL check in automount_fullpath

page is checked for null in _buildpathfromdentryoptionalprefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)

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

NFSD: fix race between nfsd registration and exports_proc

As of now nfsd calls createprocexportsentry() at start of initnfsd and cleanup by removeprocentry() at last of exit_nfsd.

Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd

for 5.4 kernel ARM64:

CPU 1: el1irq+0xbc/0x180 archcountergetcntvct+0x14/0x18 runningclock+0xc/0x18 preemptcountadd+0x88/0x110 prepnewpage+0xb0/0x220 getpagefromfreelist+0x2d8/0x1778 _allocpagesnodemask+0x15c/0xef0 _vmallocnoderange+0x28c/0x478 _vmallocnodeflagscaller+0x8c/0xb0 kvmallocnode+0x88/0xe0 nfsdinitnet+0x6c/0x108 [nfsd] opsinit+0x44/0x170 registerpernetoperations+0x114/0x270 registerpernetsubsys+0x34/0x50 initnfsd+0xa8/0x718 [nfsd] doone_initcall+0x54/0x2e0

CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010

PC is at : exportsnetopen+0x50/0x68 [nfsd]

Call trace: exportsnetopen+0x50/0x68 [nfsd] exportsprocopen+0x2c/0x38 [nfsd] procregopen+0xb8/0x198 dodentryopen+0x1c4/0x418 vfsopen+0x38/0x48 pathopenat+0x28c/0xf18 dofilpopen+0x70/0xe8 dosysopen+0x154/0x248

Sometimes it crashes at exportsnetopen() and sometimes cacheseqnext_rcu().

and same is happening on latest 6.14 kernel as well:

[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cacheseqnextrcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cacheseqnextrcu+0x78/0xa4 (P) [ 285.470488] seqread+0xe0/0x11c [ 285.470675] procregread+0x9c/0xf0 [ 285.470874] vfsread+0xc4/0x2fc [ 285.471057] ksysread+0x6c/0xf4 [ 285.471231] _arm64sysread+0x1c/0x28 [ 285.471428] invokesyscall+0x44/0x100 [ 285.471633] el0svccommon.constprop.0+0x40/0xe0 [ 285.471870] doel0svccompat+0x1c/0x34 [ 285.472073] el0svccompat+0x2c/0x80 [ 285.472265] el0t32synchandler+0x90/0x140 [ 285.472473] el0t32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---

It reproduced simply with below script: while [ 1 ] do /exportfs -r done &

while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &

So exporting interfaces to user space shall be done at last and cleanup at first place.

With change there is no Kernel OOPs.(CVE-2025-38232)

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

smb: client: fix potential deadlock when reconnecting channels

Fix cifssignalcifsdforreconnect() to take the correct lock order and prevent the following deadlock from happening

====================================================== WARNING: possible circular locking dependency detected

6.16.0-rc3-build2+ #1301 Tainted: G S W

cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcpses->srvlock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0x134/0x200

but task is already holding lock: ffff888119c64330 (&retbuf->chanlock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0xcf/0x200

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&retbuf->chanlock){+.+.}-{3:3}: validatechain+0x1cf/0x270 _lockacquire+0x60e/0x780 lockacquire.part.0+0xb4/0x1f0 rawspinlock+0x2f/0x40 cifssetupsession+0x81/0x4b0 cifsgetsmbses+0x771/0x900 cifsmountgetsession+0x7e/0x170 cifsmount+0x92/0x2d0 cifssmb3domount+0x161/0x460 smb3gettree+0x55/0x90 vfsgettree+0x46/0x180 donewmount+0x1b0/0x2e0 pathmount+0x6ee/0x740 domount+0x98/0xe0 _dosysmount+0x148/0x180 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x76/0x7e

-> #1 (&retbuf->seslock){+.+.}-{3:3}: validatechain+0x1cf/0x270 _lockacquire+0x60e/0x780 lockacquire.part.0+0xb4/0x1f0 rawspinlock+0x2f/0x40 cifsmatchsuper+0x101/0x320 sget+0xab/0x270 cifssmb3domount+0x1e0/0x460 smb3gettree+0x55/0x90 vfsgettree+0x46/0x180 donewmount+0x1b0/0x2e0 pathmount+0x6ee/0x740 domount+0x98/0xe0 _dosysmount+0x148/0x180 dosyscall64+0xa4/0x260 entrySYSCALL64after_hwframe+0x76/0x7e

-> #0 (&tcpses->srvlock){+.+.}-{3:3}: checknoncircular+0x95/0xc0 checkprevadd+0x115/0x2f0 validatechain+0x1cf/0x270 _lockacquire+0x60e/0x780 lockacquire.part.0+0xb4/0x1f0 _rawspinlock+0x2f/0x40 cifssignalcifsdforreconnect+0x134/0x200 _cifsreconnect+0x8f/0x500 cifshandlestandard+0x112/0x280 cifsdemultiplexthread+0x64d/0xbc0 kthread+0x2f7/0x310 retfromfork+0x2a/0x230 retfromforkasm+0x1a/0x30

other info that might help us debug this:

Chain exists of: &tcpses->srvlock --> &retbuf->seslock --> &retbuf->chanlock

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(&retbuf->chanlock); lock(&retbuf->seslock); lock(&retbuf->chanlock); lock(&tcpses->srvlock);

* DEADLOCK *

3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifstcpseslock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0x7b/0x200 #1: ffff888119c64060 (&retbuf->seslock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0x9c/0x200 #2: ffff888119c64330 (&retbuf->chanlock){+.+.}-{3:3}, at: cifssignalcifsdfor_reconnect+0xcf/0x200(CVE-2025-38244)

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

Bluetooth: eir: Fix possible crashes on eircreateadv_data

eircreateadvdata may attempt to add EIRFLAGS and EIRTXPOWER without checking if that would fit.(CVE-2025-38303)

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

software node: Correct a OOB check in softwarenodegetreferenceargs()

softwarenodegetreferenceargs() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.

Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)

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

NFSv4/pNFS: Fix a race to wake on NFSLAYOUTDRAIN

We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFSLAYOUTDRAIN bit in pnfsupdatelayout(), however the pnfslayouthdr's plh_outstanding count was zero.

It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.(CVE-2025-38393)

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

KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight

Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvmvmioctlcreatevcpu() is in the section between incrementing createdvcpus and onlinevcpus. The bulk of vCPU creation runs outside of kvm->lock to allow creating multiple vCPUs in parallel, and so sevinfo.esactive can get toggled from false=>true in the destination VM after (or during) svmvcpucreate(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.

The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.

BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constanttestbit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:archtestbit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:testbit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:_freepages+0x3e/0x120 mm/pagealloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> sevfreevcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svmvcpufree+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvmarchvcpudestroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvmvcpudestroy virt/kvm/kvmmain.c:470 [inline] kvmdestroyvcpus+0xd1/0x300 virt/kvm/kvmmain.c:490 kvmarchdestroyvm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvmputkvm+0xb8e/0xfb0 virt/kvm/kvmmain.c:1310 kvmvmrelease+0x48/0x60 virt/kvm/kvmmain.c:1369 _fput+0x3e4/0x9e0 fs/filetable.c:465 taskworkrun+0x1a9/0x220 kernel/taskwork.c:227 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0x7f0/0x25b0 kernel/exit.c:953 dogroupexit+0x203/0x2d0 kernel/exit.c:1102 getsignal+0x1357/0x1480 kernel/signal.c:3034 archdosignalorrestart+0x40/0x690 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:111 [inline] exittousermodeprepare include/linux/entry-common.h:329 [inline] _syscallexittousermodework kernel/entry/common.c:207 [inline] syscallexittousermode+0x67/0xb0 kernel/entry/common.c:218 dosyscall64+0x7c/0x150 arch/x86/entry/syscall64.c:100 entrySYSCALL64after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 </TASK> Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---

Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated---(CVE-2025-38455)

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

s390/bpf: Fix bpfarchtextpoke() with newaddr == NULL again

Commit 7ded842b356d ("s390/bpf: Fix bpfplt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpfarchtextpoke() with newaddr == NULL"), causing intermittent kernel panics in e.g. perf's onswitch() prog to reappear.

Restore the fix and add a comment.(CVE-2025-38489)

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

iommu/amd: Avoid stack buffer overflow from kernel cmdline

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

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

iommufd: Prevent ALIGN() overflow

When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova.

Open code the ALIGN() using getaddoverflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either.

Consolidate the two copies of this code under a single helper.

This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.(CVE-2025-38688)

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

jfs: upper bound check of tree index in dbAllocAG

When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)

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

hfsplus: don't use BUGON() in hfspluscreateattributesfile()

When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplusfillsuper() assumes that the attributes file is not yet created, which later results in hitting BUGON() when hfspluscreateattributesfile() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)

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

hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()

The hfsplusreaddir() method is capable to crash by calling hfsplusuni2asc():

[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplusuni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dumpstacklvl+0x10e/0x1f0 [ 667.124911][ T9805] printreport+0xd0/0x660 [ 667.124920][ T9805] ? virtaddrvalid+0x81/0x610 [ 667.124928][ T9805] ? _physaddr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplusuni2asc+0x902/0xa10 [ 667.124942][ T9805] kasanreport+0xc6/0x100 [ 667.124950][ T9805] ? hfsplusuni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplusuni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplusbnoderead+0x14b/0x360 [ 667.124974][ T9805] hfsplusreaddir+0x845/0xfc0 [ 667.124984][ T9805] ? _pfxhfsplusreaddir+0x10/0x10 [ 667.124994][ T9805] ? stacktracesave+0x8e/0xc0 [ 667.125008][ T9805] ? iteratedir+0x18b/0xb20 [ 667.125015][ T9805] ? tracelockacquire+0x85/0xd0 [ 667.125022][ T9805] ? lockacquire+0x30/0x80 [ 667.125029][ T9805] ? iteratedir+0x18b/0xb20 [ 667.125037][ T9805] ? downreadkillable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? _pfxdownreadkillable+0x10/0x10 [ 667.125058][ T9805] ? apparmorfilepermission+0x239/0x3e0 [ 667.125069][ T9805] iteratedir+0x296/0xb20 [ 667.125076][ T9805] _x64sysgetdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? _pfxx64sysgetdents64+0x10/0x10 [ 667.125091][ T9805] ? _x64sysopenat+0x141/0x200 [ 667.125126][ T9805] ? _pfxfilldir64+0x10/0x10 [ 667.125134][ T9805] ? douseraddrfault+0x7fe/0x12f0 [ 667.125143][ T9805] dosyscall64+0xc9/0x480 [ 667.125151][ T9805] entrySYSCALL64afterhwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIGRAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasansavestack+0x20/0x40 [ 667.146352][ T9805] kasansavetrack+0x14/0x30 [ 667.146717][ T9805] _kasankmalloc+0xaa/0xb0 [ 667.147065][ T9805] _kmallocnoprof+0x205/0x550 [ 667.147448][ T9805] hfsplusfindinit+0x95/0x1f0 [ 667.147813][ T9805] hfsplusreaddir+0x220/0xfc0 [ 667.148174][ T9805] iteratedir+0x296/0xb20 [ 667.148549][ T9805] _x64sysgetdents64+0x13c/0x2c0 [ 667.148937][ T9805] dosyscall64+0xc9/0x480 [ 667.149291][ T9805] entrySYSCALL64after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)

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

hfsplus: fix slab-out-of-bounds in hfsplusbnoderead()

The hfsplusbnoderead() method can trigger the issue:

[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplusbnoderead+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dumpstacklvl+0x10e/0x1f0 [ 174.854305][ T9784] printreport+0xd0/0x660 [ 174.854315][ T9784] ? virtaddrvalid+0x81/0x610 [ 174.854323][ T9784] ? _physaddr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplusbnoderead+0x2f4/0x360 [ 174.854337][ T9784] kasanreport+0xc6/0x100 [ 174.854346][ T9784] ? hfsplusbnoderead+0x2f4/0x360 [ 174.854354][ T9784] hfsplusbnoderead+0x2f4/0x360 [ 174.854362][ T9784] hfsplusbnodedump+0x2ec/0x380 [ 174.854370][ T9784] ? _pfxhfsplusbnodedump+0x10/0x10 [ 174.854377][ T9784] ? hfsplusbnodewriteu16+0x83/0xb0 [ 174.854385][ T9784] ? srcugpstart+0xd0/0x310 [ 174.854393][ T9784] ? _markinodedirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplusbrecremove+0x3d2/0x4e0 [ 174.854411][ T9784] _hfsplusdeleteattr+0x290/0x3a0 [ 174.854419][ T9784] ? _pfxhfsfind1strecbycnid+0x10/0x10 [ 174.854427][ T9784] ? _pfxhfsplusdeleteattr+0x10/0x10 [ 174.854436][ T9784] ? _asanmemset+0x23/0x50 [ 174.854450][ T9784] hfsplusdeleteallattrs+0x262/0x320 [ 174.854459][ T9784] ? _pfxhfsplusdeleteallattrs+0x10/0x10 [ 174.854469][ T9784] ? rcuiswatching+0x12/0xc0 [ 174.854476][ T9784] ? _markinodedirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplusdeletecat+0x845/0xde0 [ 174.854493][ T9784] ? _pfxhfsplusdeletecat+0x10/0x10 [ 174.854507][ T9784] hfsplusunlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? _pfxhfsplusunlink+0x10/0x10 [ 174.854525][ T9784] ? downwrite+0x148/0x200 [ 174.854532][ T9784] ? _pfxdownwrite+0x10/0x10 [ 174.854540][ T9784] vfsunlink+0x2fe/0x9b0 [ 174.854549][ T9784] dounlinkat+0x490/0x670 [ 174.854557][ T9784] ? _pfxdounlinkat+0x10/0x10 [ 174.854565][ T9784] ? _mightfault+0xbc/0x130 [ 174.854576][ T9784] ? getnameflags.part.0+0x1c5/0x550 [ 174.854584][ T9784] _x64sysunlink+0xc5/0x110 [ 174.854592][ T9784] dosyscall64+0xc9/0x480 [ 174.854600][ T9784] entrySYSCALL64afterhwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIGRAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasansavestack+0x20/0x40 [ 174.880082][ T9784] kasansavetrack+0x14/0x30 [ 174.880500][ T9784] _kasankmalloc+0xaa/0xb0 [ 174.880908][ T9784] _kmallocnoprof+0x205/0x550 [ 174.881337][ T9784] _hfsbnodecreate+0x107/0x890 [ 174.881779][ T9784] hfsplusbnodefind+0x2d0/0xd10 [ 174.882222][ T9784] hfsplusbrecfind+0x2b0/0x520 [ 174.882659][ T9784] hfsplusdeleteall_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)

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

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

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

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

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

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

ksmbd: fix refcount leak causing resource not released

When ksmbdconnreleasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.(CVE-2025-39720)

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

crypto: qat - flush misc workqueue during device shutdown

Repeated loading and unloading of a device specific QAT driver, for example qat4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded.

Since the driver uses a shared workqueue (qat_misc_wq) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following:

BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
  pm_bh_handler+0x1d2/0x250 [intel_qat]
  process_one_work+0x171/0x340
  worker_thread+0x277/0x3a0
  kthread+0xf0/0x120
  ret_from_fork+0x2d/0x50

To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.

Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.(CVE-2025-39721)

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

NFS: Fix filehandle bounds checking in nfsfhto_dentry()

The function needs to check the minimal filehandle length before it can access the embedded filehandle.(CVE-2025-39730)

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

mm/kmemleak: avoid soft lockup in _kmemleakdo_cleanup()

A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.

watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]

The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIGDEBUGKMEMLEAKMEMPOOL_SIZE set to 40,000.

The soft lockup happened in kmemleakdocleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a rawspinlock has to be acquired and released in _delete_object(), it could take a while to properly handle all these objects.

As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)

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

rcu: Protect ->deferqsiw_pending from data race

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

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

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

BUG: KCSAN: data-race in rcupreemptdeferredqshandler / rcureadunlock_special

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

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

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

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

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

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

NFS: Fix the setting of capabilities when automounting a new filesystem

Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.(CVE-2025-39798)

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

KVM: x86: use arrayindexnospec with indices that come from guest

min and destid are guest-controlled indices. Using arrayindex_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)

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

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

syzbot reported the splat below. [0]

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

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

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

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

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

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

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

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

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

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

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

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

cifs: prevent NULL pointer dereference in UTF16 conversion

There can be a NULL pointer dereference bug here. NULL is passed to _cifssfumakenode without checks, which passes it unchecked to cifsstrnduptoutf16, which in turn passes it to cifslocaltoutf16_bytes where '*from' is dereferenced, causing a crash.

This patch adds a check for NULL 'src' in cifsstrndupto_utf16 and returns NULL early to prevent dereferencing NULL pointer.

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

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

batman-adv: fix OOB read/write in network-coding decode

batadvncskbdecodepacket() trusts codedlen and checks only against skb->len. XOR starts at sizeof(struct batadvunicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.

Validate that codedlen fits within the payload area of both destination and source skbuffs before XORing.(CVE-2025-39839)

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

ceph: fix race condition validating r_parent before applying state

Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes.

[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPHCAPPIN reference when r_parent is updated:

When the parent directory lock is not held, req->rparent can become stale and is updated to point to the correct inode. However, the associated CEPHCAPPIN reference was not being adjusted. The CEPHCAPPIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in cephmdscreleaserequest(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ](CVE-2025-39927)

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

smb: client: fix smbdirectrecvio leak in smbd_negotiate() error path

During tests of another unrelated patch I was able to trigger this error: Objects remaining on _kmemcache_shutdown()(CVE-2025-39929)

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

um: virtiouml: Fix use-after-free after putdevice in probe

When registervirtiodevice() fails in virtioumlprobe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)

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

net/sched: schqfq: Fix null-deref in aggdequeue

To prevent a potential crash in aggdequeue (net/sched/schqfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c.

To avoid code duplication, the following changes are made:

Changed qdiscwarnnonwc(include/net/pkt_sched.h) into a static inline function.
Moved qdiscpeeklen from net/sched/schhfsc.c to include/net/pktsched.h so that sch_qfq can reuse it.
Applied qdiscpeeklen in agg_dequeue to avoid crashing.(CVE-2025-40083)

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

NFSD: Define a proc_layoutcommit for the FlexFiles layout type

Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.(CVE-2025-40087)

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

cifs: parsedfsreferrals: prevent oob on malformed input

Malicious SMB server can send invalid reply to FSCTLDFSGET_REFERRALS

reply smaller than sizeof(struct getdfsreferral_rsp)
reply with number of referrals smaller than NumberOfReferrals in the header

Processing of such replies will cause oob.

Return -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)

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

smb: client: Fix refcount leak for cifssbtlink

Fix three refcount inconsistency issues related to cifs_sb_tlink.

Comments for cifs_sb_tlink state that cifs_put_tlink() needs to be called after successful calls to cifs_sb_tlink(). Three calls fail to update refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)

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

vfs: Don't leak disconnected dentries on umount

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

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

drm/vmwgfx: Fix Use-after-free in validation

Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmwexecbufprocess. All nodes are expected to be cleared in vmwvalidationdrop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)

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

net/mlx5: Clean up only new IRQ glue on request_irq() failure

The mlx5irqalloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added.

This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object.

Note: This error is observed when both fwctl and rds configs are enabled.

[1] mlx5core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5core 0000:05:00.0: mlx5irqalloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx50: mlx5ibtestwc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5core 0000:06:00.0: mlx5irqalloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx50: mlx5ibtestwc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5core 0000:03:00.0: mlx5irqalloc:293:(pid 28895): Failed to request irq. err = -28 mlx5core 0000:05:00.0: mlx5irqalloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI

RIP: 0010:freeirqcpurmap+0x23/0x7d Call Trace: <TASK> ? showtraceloglvl+0x1d6/0x2f9 ? showtraceloglvl+0x1d6/0x2f9 ? mlx5irqalloc.cold+0x5d/0xf3 [mlx5core] ? diebody.cold+0x8/0xa ? dieaddr+0x39/0x53 ? excgeneralprotection+0x1c4/0x3e9 ? devvprintkemit+0x5f/0x90 ? asmexcgeneralprotection+0x22/0x27 ? freeirqcpurmap+0x23/0x7d mlx5irqalloc.cold+0x5d/0xf3 [mlx5core] irqpoolrequestvector+0x7d/0x90 [mlx5core] mlx5irqrequest+0x2e/0xe0 [mlx5core] mlx5irqrequestvector+0xad/0xf7 [mlx5core] compirqrequestpci+0x64/0xf0 [mlx5core] createcompeq+0x71/0x385 [mlx5core] ? mlx5eopenxdpsq+0x11c/0x230 [mlx5core] mlx5compeqnget+0x72/0x90 [mlx5core] ? xasload+0x8/0x91 mlx5compirqnget+0x40/0x90 [mlx5core] mlx5eopenchannel+0x7d/0x3c7 [mlx5core] mlx5eopenchannels+0xad/0x250 [mlx5core] mlx5eopenlocked+0x3e/0x110 [mlx5core] mlx5eopen+0x23/0x70 [mlx5core] _devopen+0xf1/0x1a5 _devchangeflags+0x1e1/0x249 devchangeflags+0x21/0x5c dosetlink+0x28b/0xcc4 ? _nlaparse+0x22/0x3d ? inet6validatelinkaf+0x6b/0x108 ? cpumasknext+0x1f/0x35 ? _snmp6fillstats64.constprop.0+0x66/0x107 ? _nlavalidateparse+0x48/0x1e6 _rtnlnewlink+0x5ff/0xa57 ? kmemcachealloctrace+0x164/0x2ce rtnlnewlink+0x44/0x6e rtnetlinkrcvmsg+0x2bb/0x362 ? _netlinksendskb+0x4c/0x6c ? netlinkunicast+0x28f/0x2ce ? rtnlcalcit.isra.0+0x150/0x146 netlinkrcvskb+0x5f/0x112 netlinkunicast+0x213/0x2ce netlinksendmsg+0x24f/0x4d9 _socksendmsg+0x65/0x6a syssendmsg+0x28f/0x2c9 ? importiovec+0x17/0x2b _syssendmsg+0x97/0xe0 _syssendmsg+0x81/0xd8 dosyscall64+0x35/0x87 entrySYSCALL64afterhwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---(CVE-2025-40250)

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

net: qlogic/qede: fix potential out-of-bounds read in qedetpacont() and qedetpaend()

The loops in 'qedetpacont()' and 'qedetpaend()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array.

Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access.

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

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

scsi: sg: Do not sleep in atomic context

sgfinishremreq() calls blkrqunmapuser(). The latter function may sleep. Hence, call sgfinishrem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)

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

nvme: nvme-fc: Ensure ->ioerrwork is cancelled in nvmefcdeletectrl()

nvmefcdeleteassocation() waits for pending I/O to complete before returning, and an error can cause ->ioerrwork to be queued after cancelworksync() had been called. Move the call to cancelworksync() to be after nvmefcdeleteassociation() to ensure ->ioerrwork is not running when the nvmefcctrl object is freed. Otherwise the following can occur:

[ 1135.911754] listdel corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/listdebug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:_listdelentryvalidorreport.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.067540] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.071898] ? movelinkedworks+0x4a/0xa0 [ 1136.075998] ? _listdelentryvalidorreport.cold+0xf/0x6f [ 1136.081744] ? _diebody.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? dotrap+0xca/0x110 [ 1136.091789] ? doerrortrap+0x65/0x80 [ 1136.095543] ? _listdelentryvalidorreport.cold+0xf/0x6f [ 1136.101289] ? excinvalidop+0x50/0x70 [ 1136.105127] ? _listdelentryvalidorreport.cold+0xf/0x6f [ 1136.110874] ? asmexcinvalidop+0x1a/0x20 [ 1136.115059] ? _listdelentryvalidorreport.cold+0xf/0x6f [ 1136.120806] movelinkedworks+0x4a/0xa0 [ 1136.124733] workerthread+0x216/0x3a0 [ 1136.128485] ? _pfxworkerthread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? _pfxkthread+0x10/0x10 [ 1136.139657] retfromfork+0x31/0x50 [ 1136.143236] ? _pfxkthread+0x10/0x10 [ 1136.146988] retfromfork_asm+0x1a/0x30 [ 1136.150915] </TASK>(CVE-2025-40261)

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

be2net: pass wrb_params in case of OS2BMC

beinsertvlaninpkt() is called with the wrbparams argument being NULL at besendpktto_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states.

The correct way would be to pass the wrbparams from bexmit().(CVE-2025-40264)

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

cifs: client: fix memory leak in smb3fscontextparseparam

The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation.

To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing.

syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3fscontextparseparam+0x229b/0x36c0 fs/smb/client/fs_context.c:1444

BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3fscontextfullpath+0x70/0x1b0 fs/smb/client/fscontext.c:629 smb3fscontextparseparam+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)

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

NFSD: free copynotify stateid in nfs4freeol_stateid()

Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period.

However, in case when the server got an OPEN (which created a parent stateid), followed by a COPYNOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATESESSION would force expire previous state of this client. It leads to the open state being freed thru releaseopenowner-> nfs4freeolstateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred

WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4freeol_stateid+0xb0/0x100 [nfsd]

This patch, instead, frees the associated copynotify stateid here.

If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later.

[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlinkqueue nfnetlinklog bluetooth cfg80211 rpcrdma rdmacm iwcm ibcm ibcore nfsd nfsacl lockd grace nfslocalio ext4 crc16 mbcache jbd2 overlay uinput sndseqdummy sndhrtimer qrtr rfkill vfat fat uvcvideo sndhdacodecgeneric videobuf2vmalloc videobuf2memops sndhdaintel uvc sndinteldspcfg videobuf2v4l2 videobuf2common sndhdacodec sndhdacore videodev sndhwdep sndseq mc sndseqdevice sndpcm sndtimer snd soundcore sg loop authrpcgss vsockloopback vmwvsockvirtiotransportcommon vmwvsockvmcitransport vmwvmci vsock xfs 8021q garp stp llc mrp nvme ghashce e1000e nvmecore srmod nvmekeyring nvmeauth cdrom vmwgfx drmttmhelper ttm sunrpc dmmirror dmregionhash dmlog iscsitcp libiscsitcp libiscsi scsitransportiscsi fuse dmmultipath dmmod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BADPAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromatmain [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : _listdelentryvalidorreport+0x148/0x200 [ 1626.860601] lr : _listdelentryvalidorreport+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] _listdelentryvalidorreport+0x148/0x200 (P) [ 1626.868876] _freecpntfstatelocked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromatmain+0x24/0x60 [nfsd] [ 1626.870231] processonework+0x584/0x1050 [ 1626.870595] workerthread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] retfrom_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)

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

Bluetooth: MGMT: cancel mesh send timer when hdev removed

meshsenddone timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone.

Cancel the timer when MGMT removes the hdev, like other MGMT timers.

Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test).

Log:

BUG: KASAN: slab-use-after-free in runtimersoftirq+0x76b/0x7d0 ... Freed by task 36: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 _kasansavefreeinfo+0x3a/0x60 _kasanslabfree+0x43/0x70 kfree+0x103/0x500 devicerelease+0x9a/0x210 kobjectput+0x100/0x1e0 vhcirelease+0x18b/0x240 ------(CVE-2025-40284)

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

fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds

Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches.

Without the character count update, bitputcsaligned and bitputcsunaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)

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

accel/habanalabs: support mapping cb with vmalloc-backed coherent memory

When IOMMU is enabled, dmaalloccoherent() with GFPUSER may return addresses from the vmalloc range. If such an address is mapped without VMMIXEDMAP, vminsertpage() will trigger a BUGON due to the VMPFNMAP restriction.

Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.(CVE-2025-40311)

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

usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget

In the _cdnspgadgetinit() and cdnspgadgetexit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the eplist in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free.

Fix: By separating the usbdelgadgetudc() operation into distinct "del" and "put" steps, cdnspgadgetfreeendpoints() can be executed prior to the final release of the gadget structure with usbputgadget().

A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").(CVE-2025-40314)

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

bpf: Sync pending IRQ work before freeing ring buffer

Fix a race where irqwork can be queued in bpfringbufcommit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to schedswitch triggers bpfringbufcommit(), queuing an irqwork. If the ring buffer is freed before this work executes, the irqwork thread may accesses freed memory. Calling irq_work_sync(&rb->work) ensures that all pending irq_work complete before freeing the buffer.(CVE-2025-40319)

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

smb: client: fix potential cfid UAF in smb2queryinfo_compound

When smb2queryinfo_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free.

Reinitialize cfid to NULL under the replay label.

Example trace (trimmed):

refcountt: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcountwarnsaturate+0x9c/0x110 [...] RIP: 0010:refcountwarnsaturate+0x9c/0x110 [...] Call Trace: <TASK> smb2queryinfocompound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? stepinto+0x10d/0x690 ? _legitimizepath+0x28/0x60 smb2queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmemcachealloc+0x18a/0x340 ? getnameflags+0x46/0x1e0 cifsstatfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfsbydentry+0x67/0x90 vfsstatfs+0x16/0xd0 userstatfs+0x54/0xa0 _dosysstatfs+0x20/0x50 dosyscall64+0x58/0x80(CVE-2025-40320)

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

fbdev: bitblit: bound-check glyph index in bit_putcs*

bitputcsaligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.

This fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)

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

NFSD: Fix crash in nfsd4readrelease()

When tracing is enabled, the tracenfsdread_done trace point crashes during the pynfs read.testNoFh test.(CVE-2025-40324)

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

smb: client: fix potential UAF in smb2closecached_fid()

findorcreatecacheddir() could grab a new reference after krefput() had seen the refcount drop to zero but before cfidlistlock is acquired in smb2closecachedfid(), leading to use-after-free.

Switch to krefputlock() so cfidrelease() is called with cfidlist_lock held, closing that gap.(CVE-2025-40328)

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

usb: storage: sddr55: Reject out-of-bound new_pba

Discovered by Atuin - Automated Vulnerability Discovery Engine.

newpba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pbato_lba[] and corrupt heap memory.

Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)

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

net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ

XDP programs can change the layout of an xdpbuff through bpfxdpadjusttail() and bpfxdpadjusthead(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdpbuff after XDP programs run.

Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdpbuff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpfxdpadjusthead(), the linear data will be ignored as mlx5ebuildlinearskb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpfxdpadjusttail(), the delta passed to _pskbpulltail() may exceed the actual nonlinear data size and trigger the BUGON in it.

To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.(CVE-2025-40350)

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

drm/sysfb: Do not dereference NULL pointer in plane reset

The plane state in _drmgemresetshadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.

v2: - fix typo in commit description (Javier)(CVE-2025-40360)

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

net: ipv6: fix field-spanning memcpy warning in AH output

Fix field-spanning memcpy warnings in ah6output() and ah6output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields.

memcpy: detected field-spanning write (size 40) of single field "&topiph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6output+0xe7e/0x14e0 net/ipv6/ah6.c:439

The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.(CVE-2025-40363)

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

blk-cgroup: fix possible deadlock while configuring policy

Following deadlock can be triggered easily by lockdep:

WARNING: possible circular locking dependency detected

6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted

check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfslock){+.+.}-{4:4}, at: blkunregister_queue+0x53/0x180

but task is already holding lock: ff1100011d9d00e0 (&q->qusagecounter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&q->qusagecounter(queue)#3){++++}-{0:0}: blkqueueenter+0x40b/0x470 blkgconfprep+0x7b/0x3c0 tgsetlimit+0x10a/0x3e0 cgroupfilewrite+0xc6/0x420 kernfsfopwriteiter+0x189/0x280 vfswrite+0x256/0x490 ksyswrite+0x83/0x190 _x64syswrite+0x21/0x30 x64syscall+0x4608/0x4630 dosyscall64+0xdb/0x6b0 entrySYSCALL64afterhwframe+0x76/0x7e

-> #1 (&q->rqqosmutex){+.+.}-{4:4}: _mutexlock+0xd8/0xf50 mutexlocknested+0x2b/0x40 wbtinit+0x17e/0x280 wbtenabledefault+0xe9/0x140 blkregisterqueue+0x1da/0x2e0 _adddisk+0x38c/0x5d0 adddiskfwnode+0x89/0x250 deviceadddisk+0x18/0x30 virtblkprobe+0x13a3/0x1800 virtiodevprobe+0x389/0x610 reallyprobe+0x136/0x620 _driverprobedevice+0xb3/0x230 driverprobedevice+0x2f/0xe0 _driverattach+0x158/0x250 busforeachdev+0xa9/0x130 driverattach+0x26/0x40 busadddriver+0x178/0x3d0 driverregister+0x7d/0x1c0 _registervirtiodriver+0x2c/0x60 virtioblkinit+0x6f/0xe0 dooneinitcall+0x94/0x540 kernelinitfreeable+0x56a/0x7b0 kernelinit+0x2b/0x270 retfromfork+0x268/0x4c0 retfromforkasm+0x1a/0x30

-> #0 (&q->sysfslock){+.+.}-{4:4}: _lockacquire+0x1835/0x2940 lockacquire+0xf9/0x450 _mutexlock+0xd8/0xf50 mutexlocknested+0x2b/0x40 blkunregisterqueue+0x53/0x180 _delgendisk+0x226/0x690 delgendisk+0xba/0x110 sdremove+0x49/0xb0 [sdmod] deviceremove+0x87/0xb0 devicereleasedriverinternal+0x11e/0x230 devicereleasedriver+0x1a/0x30 busremovedevice+0x14d/0x220 devicedel+0x1e1/0x5a0 _scsiremovedevice+0x1ff/0x2f0 scsiremovedevice+0x37/0x60 sdevstoredelete+0x77/0x100 devattrstore+0x1f/0x40 sysfskfwrite+0x65/0x90 kernfsfopwriteiter+0x189/0x280 vfswrite+0x256/0x490 ksyswrite+0x83/0x190 _x64syswrite+0x21/0x30 x64syscall+0x4608/0x4630 dosyscall64+0xdb/0x6b0 entrySYSCALL64after_hwframe+0x76/0x7e

other info that might help us debug this:

Chain exists of: &q->sysfslock --> &q->rqqosmutex --> &q->qusage_counter(queue)#3

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(&q->qusagecounter(queue)#3); lock(&q->rqqosmutex); lock(&q->qusagecounter(queue)#3); lock(&q->sysfs_lock);

Root cause is that queueusagecounter is grabbed with rqqosmutex held in blkgconfprep(), while queue should be freezed before rqqosmutex from other context.

The blkqueueenter() from blkgconfprep() is used to protect against policy deactivation, which is already protected with blkcgmutex, hence convert blkqueueenter() to blkcgmutex to fix this problem. Meanwhile, consider that blkcgmutex is held after queue is freezed from policy deactivation, also convert blkgalloc() to use GFP_NOIO.(CVE-2025-68178)

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

drm/mediatek: Disable AFBC support on Mediatek DRM driver

Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier.

However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0.

Kernel trace reports vblank timeouts constantly, and the render is garbled:

[CRTC:62:crtc-0] vblank wait timed out
WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
[...]
Hardware name: MediaTek Genio-700 EVK (DT)
Workqueue: events_unbound commit_work
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
sp : ffff80008337bca0
x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000
x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000
x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80
x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a
x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b
x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70
x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70
x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480
Call trace:
 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)
 drm_atomic_helper_commit_tail_rpm+0x64/0x80
 commit_tail+0xa4/0x1a4
 commit_work+0x14/0x20
 process_one_work+0x150/0x290
 worker_thread+0x2d0/0x3ec
 kthread+0x12c/0x210
 ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---

Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.(CVE-2025-68184)

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

nfs4setupreaddir(): insufficient locking for ->dparent->dinode dereferencing

Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack.

Anyway, it's easy to deal with - since xdrencodehyper() is just a call of putunalignedbe64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)

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

udptunnel: use netdevwarn() instead of netdev_WARN()

netdevWARN() uses WARN/WARNON to print a backtrace along with file and line information. In this case, udptunnelnic_register() returning an error is just a failed operation, not a kernel bug.

udptunnelnicregister() can fail due to a memory allocation failure (kzalloc() or udptunnelnicalloc()). This is a normal runtime error and not a kernel bug.

Replace netdevWARN() with netdevwarn() accordingly.(CVE-2025-68191)

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

nvme-multipath: fix lockdep WARN due to partition scan work

Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->openmutex, kblockd workqueue completion and partitionscan_work completion.

To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partitionscanwork not by kblockd workqueue but by nvme_wq.(CVE-2025-68218)

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

cifs: fix memory leak in smb3fscontextparseparam error path

Add proper cleanup of ctx->source and fc->source to the cifsparsemounterr error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3cleanupfscontext_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues.

This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed.

The specific leak sequence was: 1. ctx->source = smb3fscontextfullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFPKERNEL) allocates more memory 3. A subsequent error jumps to cifsparsemount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak.

This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3fscontextparseparam"), which only fixed leaks from repeated fsconfig() calls but not this error path.

Patch updated with minor change suggested by kernel test robot(CVE-2025-68219)

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

scsi: target: tcmloop: Fix segfault in tcmlooptpgaddress_show()

If the allocation of tlhba->sh fails in tcmloopdriverprobe() and we attempt to dereference it in tcmlooptpgaddressshow() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.

Unable to allocate struct scsihost BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcmlooptpgaddressshow+0x2e/0x50 [tcmloop] ... Call Trace: <TASK> configfsreaditer+0x12d/0x1d0 [configfs] vfsread+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)

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

binfmtmisc: restore write access before closing files opened by openexec()

bmregisterwrite() opens an executable file using openexec(), which internally calls doopen_execat() and denies write access on the file to avoid modification while it is being executed.

However, when an error occurs, bmregisterwrite() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail.

Fix this by calling exefileallowwriteaccess() before filp_close() to restore the write permission properly.(CVE-2025-68239)

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

ipv4: route: Prevent rtbindexception() from rebinding stale fnhe

The sit driver's packet transmission path calls: sittunnelxmit() -> updateorcreatefnhe(), which lead to fnheremoveoldest() being called to delete entries exceeding FNHERECLAIM_DEPTH+random.

The race window is between fnheremoveoldest() selecting fnheX for deletion and the subsequent kfreercu(). During this time, the concurrent path's _mkrouteoutput() -> findexception() can fetch the soon-to-be-deleted fnheX, and rtbindexception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked.

CPU 0 CPU 1 _mkrouteoutput() findexception() [fnheX] updateorcreatefnhe() fnheremoveoldest() [fnheX] rtbindexception() [bind dst] RCU callback [fnheX freed, dst leak]

This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device:

unregister_netdevice: waiting for sitX to become free. Usage count = N

Ido Schimmel provided the simple test validation method [1].

The fix clears 'oldest->fnhedaddr' before calling fnheflushroutes(). Since rtbind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed.

[1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1(CVE-2025-68241)

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

net: netpoll: fix incorrect refcount handling causing incorrect cleanup

commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks.

Scenario causing lack of proper cleanup:

1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.

2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.

3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls RCU_INIT_POINTER(np->dev->npinfo, NULL); - Set dev->npinfo = NULL, without proper cleanup - No ->ndonetpollcleanup() is either called

4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndonetpollcleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.

Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.(CVE-2025-68245)

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

erofs: avoid infinite loops due to corrupted subpage compact indexes

Robert reported an infinite loop observed by two crafted images.

The root cause is that clusterofs can be larger than lclustersize for !NONHEAD lclusters in corrupted subpage compact indexes, e.g.:

blocksize = lclustersize = 512 lcn = 6 clusterofs = 515

Move the corresponding check for full compress indexes to z_erofs_load_lcluster_from_disk() to also cover subpage compact compress indexes.

It also fixes the position of m->type >= Z_EROFS_LCLUSTER_TYPE_MAX check, since it should be placed right after z_erofs_load_{compact,full}_lcluster().(CVE-2025-68251)

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

usb: storage: Fix memory leak in USB bulk transport

A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355.

When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the USBULKCS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB.

Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase.

Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.(CVE-2025-68288)

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

smb: client: fix memory leak in cifsconstructtcon()

When having a multiuser mount with domain= specified and using cifscreds, cifssetcifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifsconstructtcon().

This fixes the following memory leak reported by kmemleak:

mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): _kmallocnodetrackcallernoprof+0x572/0x710 kstrdup+0x3a/0x70 cifssbtlink+0x1209/0x1770 [cifs] cifsgetfattr+0xe1/0xf50 [cifs] cifsgetinodeinfo+0xb5/0x240 [cifs] cifsrevalidatedentryattr+0x2d1/0x470 [cifs] cifsgetattr+0x28e/0x450 [cifs] vfsgetattrnosec+0x126/0x180 vfsstatx+0xf6/0x220 dostatx+0xab/0x110 _x64sysstatx+0xd5/0x130 dosyscall64+0xbb/0x380 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2025-68295)

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

drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup

Protect vgaswitcherooclientfbset() with console lock. Avoids OOB access in fbconremapall(). Without holding the console lock the call races with switching outputs.

VGA switcheroo calls fbconremapall() when switching clients. The fbcon function uses struct fbinfo.node, which is set by registerframebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within setcon2fbmap() [1] as an index into an array.

Moving vgaswitcherooclientfbset() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly.

Therefore move vgaswitcherooclientfbset() under fbconfbregistered(), which already holds the console lock. Fbdev calls fbconfbregistered() from within registerframebuffer(). Serializes the helper with VGA switcheroo's call to fbconremap_all().

Although vgaswitcherooclientfbset() takes an instance of struct fbinfo as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vgaswitcheroo. For all other drivers, this change does nothing.(CVE-2025-68296)

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

Bluetooth: hci_sock: Prevent race in socket write iter and sock bind

There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1].

Here we use hcidevlock to synchronize the two, thereby avoiding the UAF mentioned in [1].

[1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmtpendingremove+0x3b/0x210 net/bluetooth/mgmtutil.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmtpendingremove+0x3b/0x210 net/bluetooth/mgmtutil.c:316 setlinksecurity+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:727 [inline] _socksendmsg+0x21c/0x270 net/socket.c:742 sockwriteiter+0x279/0x360 net/socket.c:1195

Allocated by task 5989: mgmtpendingadd+0x35/0x140 net/bluetooth/mgmtutil.c:296 setlinksecurity+0x557/0x710 net/bluetooth/mgmt.c:1910 hcimgmtcmd+0x9c9/0xef0 net/bluetooth/hcisock.c:1719 hcisocksendmsg+0x6ca/0xef0 net/bluetooth/hcisock.c:1839 socksendmsgnosec net/socket.c:727 [inline] _socksendmsg+0x21c/0x270 net/socket.c:742 sockwrite_iter+0x279/0x360 net/socket.c:1195

Freed by task 5991: mgmtpendingfree net/bluetooth/mgmtutil.c:311 [inline] mgmtpendingforeach+0x30d/0x380 net/bluetooth/mgmtutil.c:257 mgmtindexremoved+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hcisockbind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)

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

s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump

Do not block PCI config accesses through pcicfgaccesslock() when executing the s390 variant of PCI error recovery: Acquire just devicelock() instead of pcidevlock() as powerpc's EEH and generig PCI AER processing do.

During error recovery testing a pair of tasks was reported to be hung:

mlx5core 0000:00:00.1: mlx5healthtryrecover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] _schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedulepreemptdisabled+0x22/0x30 [<0000000652570a94>] _mutexlock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5unloadone+0x34/0x58 [mlx5core] [<000003ff8006745c>] mlx5pcierrdetected+0x94/0x140 [mlx5core] [<0000000652556c5a>] zpcieventattempterrorrecovery+0xf2/0x398 [<0000000651b9184a>] _zpcieventerror+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5health0000:00:00.0 mlx5fwfatalreportererrwork [mlx5core] Call Trace: [<000000065256f030>] _schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pciwaitcfg+0x80/0xe8 [<0000000652172f94>] pcicfgaccesslock+0x74/0x88 [<000003ff800916b6>] mlx5vscgwlock+0x36/0x178 [mlx5core] [<000003ff80098824>] mlx5crdumpcollect+0x34/0x1c8 [mlx5core] [<000003ff80074b62>] mlx5fwfatalreporterdump+0x6a/0xe8 [mlx5core] [<0000000652512242>] devlinkhealthdodump.part.0+0x82/0x168 [<0000000652513212>] devlinkhealthreport+0x19a/0x230 [<000003ff80075a12>] mlx5fwfatalreportererrwork+0xba/0x1b0 [mlx5_core]

No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too:

task: kmcheck mlx5unloadone() tries to acquire devlink lock while the PCI error recovery code has set pdev->blockcfgaccess by way of pcicfgaccess_lock()
task: kworker mlx5crdumpcollect() tries to set blockcfgaccess through pcicfgaccesslock() while devlinkhealth_report() had acquired the devlink lock.

A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/<BDF> reporter fw_fatal

while PCI error recovery is executed on the same <BDF> physical function by mlx5core's pcierror_handlers. On s390 this can be injected with > zpcictl --reset-fw <BDF>

Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with "kernel answers: Permission denied" - and we get a kernel log message of:

mlx5core 1ed0:00:00.1: mlx5crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5

because the config read of VSC_SEMAPHORE is rejected by the underlying hardware.

Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.(CVE-2025-68310)

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

usbnet: Prevents free active kevent

The root cause of this issue are: 1. When probing the usbnet device, executing usbnetlinkchange(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here.

Another factor is that when calling usbnetdisconnect()->unregisternetdev(), if the usbnet device is up, ndostop() is executed to cancel the kevent. However, because the device is not up, ndostop() is not executed.

The solution to this problem is to cancel the kevent before executing free_netdev().(CVE-2025-68312)

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

nbd: defer config unlock in nbdgenlconnect

There is one use-after-free warning when running NBDCMDCONNECT and NBDCLEARSOCK:

nbdgenlconnect nbdallocandinitconfig // configrefs=1 nbdstartdevice // configrefs=2 set NBDRTHASCONFIGREF open nbd // configrefs=3 recvwork done // configrefs=2 NBDCLEARSOCK // configrefs=1 close nbd // configrefs=0 refcountinc -> uaf

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcountwarnsaturate+0x12e/0x290 nbdgenlconnect+0x16d0/0x1ab0 genlfamilyrcvmsgdoit+0x1f3/0x310 genlrcv_msg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before refcountinc(&nbd->configrefs) in nbdgenlconnect():

    mutex_unlock(&amp;nbd-&gt;config_lock);
    if (!ret) {
            set_bit(NBD_RT_HAS_CONFIG_REF, &amp;config-&gt;runtime_flags);

+ printk("before sleep\n"); + mdelay(5 * 1000); + printk("after sleep\n"); refcountinc(&nbd->configrefs); nbdconnectreply(info, nbd->index); }(CVE-2025-68366)

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

macintosh/machid: fix race condition in machidtoggleemumouse

The following warning appears when running syzkaller, and this issue also exists in the mainline code.

------------[ cut here ]------------ listadd double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/listdebug.c:35 listaddvalidorreport+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:listaddvalidorreport+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> inputregisterhandler+0xb3/0x210 machidstartemulation+0x1c5/0x290 machidtoggleemumouse+0x20a/0x240 procsyscallhandler+0x4c2/0x6e0 newsyncwrite+0x1b1/0x2d0 vfswrite+0x709/0x950 ksyswrite+0x12a/0x250 dosyscall64+0x5a/0x110 entrySYSCALL64after_hwframe+0x78/0xe2

The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in machidtoggleemumouse(). Both processes read oldval=0, then both try to register the input handler, leading to a double list_add of the same handler.

CPU0 CPU1 ------------------------- ------------------------- vfswrite() //write 1 vfswrite() //write 1 procsyswrite() procsyswrite() machidtoggleemumouse() machidtoggleemumouse() oldval = *valp // oldval=0 oldval = *valp // oldval=0 mutexlockkillable() procdointvec() // *valp=1 machidstartemulation() inputregisterhandler() mutexunlock() mutexlockkillable() procdointvec() machidstartemulation() inputregisterhandler() //Trigger Warning mutexunlock()

Fix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)

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

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.

Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.
Cancel any pending TMF work that has not started in sdev_destroy().
Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)

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

nbd: defer config put in recv_work

There is one uaf issue in recvwork when running NBDCLEARSOCK and NBDCMDRECONFIGURE: nbdgenlconnect // confref=2 (connect and recvwork A) nbdopen // confref=3 recvwork A done // confref=2 NBDCLEARSOCK // confref=1 nbdgenlreconfigure // confref=2 (trigger recvwork B) close nbd // confref=1 recvwork B configput // confref=0 atomicdec(&config->recvthreads); -> UAF

Or only running NBDCLEARSOCK: nbdgenlconnect // confref=2 nbdopen // confref=3 NBDCLEARSOCK // confref=2 close nbd nbdrelease configput // confref=1 recvwork configput // confref=0 atomicdec(&config->recvthreads); -> UAF

Commit 87aac3a80af5 ("nbd: call nbdconfigput() before notifying the waiter") moved nbdconfigput() to run before waking up the waiter in recvwork, in order to ensure that nbdstartdeviceioctl() would not be woken up while nbd->task_recv was still uncleared.

However, in nbdstartdeviceioctl(), after being woken up it explicitly calls flushworkqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.

Move nbdconfigput() to the end of recvwork, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recvwork is still running, even if clear + reconfigure interleave.

In addition, we don't need to worry about recvwork dropping the last nbdput (which causes deadlock):

path A (netlink with NBDCFLAGDESTROYONDISCONNECT): connect // nbdrefs=1 (trigger recvwork) open nbd // nbdrefs=2 NBDCLEARSOCK close nbd nbdrelease nbddisconnectandput flushworkqueue // recvwork done nbdconfigput nbdput // nbdrefs=1 nbdput // nbdrefs=0 queuework

path B (netlink without NBDCFLAGDESTROYONDISCONNECT): connect // nbdrefs=2 (trigger recvwork) open nbd // nbdrefs=3 NBDCLEARSOCK // confrefs=2 close nbd nbdrelease nbdconfigput // confrefs=1 nbdput // nbdrefs=2 recvwork done // confrefs=0, nbdrefs=1 rmmod // nbdrefs=0

Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbdconfigput")(CVE-2025-68372)

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

md: fix rcu protection in mdwakeupthread

We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling mdwakeupthread(). This means that the RCU pointer has been acquired before rcureadlock(), which renders rcureadlock() ineffective and could lead to a use-after-free.(CVE-2025-68374)

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

RDMA/rxe: Fix null deref on srq->rq.queue after resize failure

A NULL pointer dereference can occur in rxesrqchkattr() when ibvmodifysrq() is invoked twice in succession under certain error conditions. The first call may fail in rxequeueresize(), which leads rxesrqfromattr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask.

Call Trace: <TASK> rxemodifysrq+0x170/0x480 [rdmarxe] ? pfxrxemodifysrq+0x10/0x10 [rdmarxe] ? uverbstrylockobject+0x4f/0xa0 [ibuverbs] ? rdmalookupgetuobject+0x1f0/0x380 [ibuverbs] ibuverbsmodifysrq+0x204/0x290 [ibuverbs] ? _pfxibuverbsmodifysrq+0x10/0x10 [ibuverbs] ? tryincnodenractive+0xe6/0x150 ? uverbsfilludata+0xed/0x4f0 [ibuverbs] ibuverbshandlerUVERBSMETHODINVOKEWRITE+0x2c0/0x470 [ibuverbs] ? _pfxibuverbshandlerUVERBSMETHODINVOKEWRITE+0x10/0x10 [ibuverbs] ? uverbsfilludata+0xed/0x4f0 [ibuverbs] ibuverbsrunmethod+0x55a/0x6e0 [ibuverbs] ? _pfxibuverbshandlerUVERBSMETHODINVOKEWRITE+0x10/0x10 [ibuverbs] ibuverbscmdverbs+0x54d/0x800 [ibuverbs] ? _pfxibuverbscmdverbs+0x10/0x10 [ibuverbs] ? _pfxrawspinlockirqsave+0x10/0x10 ? _pfxdovfsioctl+0x10/0x10 ? ioctlhasperm.constprop.0.isra.0+0x2c7/0x4c0 ? _pfxioctlhasperm.constprop.0.isra.0+0x10/0x10 ibuverbsioctl+0x13e/0x220 [ibuverbs] ? _pfxibuverbsioctl+0x10/0x10 [ibuverbs] _x64sysioctl+0x138/0x1c0 dosyscall64+0x82/0x250 ? fdgetpos+0x58/0x4c0 ? ksyswrite+0xf3/0x1c0 ? _pfxksyswrite+0x10/0x10 ? dosyscall64+0xc8/0x250 ? _pfxvmmmappgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksysmmappgoff+0x224/0x4c0 ? dosyscall64+0xc8/0x250 ? douseraddrfault+0x37b/0xfe0 ? clearbhbloop+0x50/0xa0 ? clearbhbloop+0x50/0xa0 ? clearbhbloop+0x50/0xa0 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-68379)

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

NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags

When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.(CVE-2025-68764)

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

fsnotify: do not generate ACCESS/MODIFY events on child for special files

inotify/fanotify do not allow users with no read access to a file to subscribe to events (e.g. INACCESS/INMODIFY), but they do allow the same user to subscribe for watching events on children when the user has access to the parent directory (e.g. /dev).

Users with no read access to a file but with read access to its parent directory can still stat the file and see if it was accessed/modified via atime/mtime change.

The same is not true for special files (e.g. /dev/null). Users will not generally observe atime/mtime changes when other users read/write to special files, only when someone sets atime/mtime via utimensat().

Align fsnotify events with this stat behavior and do not generate ACCESS/MODIFY events to parent watchers on read/write of special files. The events are still generated to parent watchers on utimensat(). This closes some side-channels that could be possibly used for information exfiltration [1].

[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)

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

fuse: missing copy_finish in fuse-over-io-uring argument copies

Fix a possible reference count leak of payload pages during fuse argument copies.

Joanne: simplified error cleanup

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

perf/x86/amd: Check event before enable to avoid GPF

On AMD machines cpuc->events[idx] can become NULL in a subtle race condition with NMI->throttle->x86pmustop().

Check event for NULL in amdpmuenable_all() before enable to avoid a GPF. This appears to be an AMD only issue.

Syzkaller reported a GPF in amdpmuenable_all.

INFO: NMI handler (perfeventnmihandler) took too long to run: 13.143 msecs Oops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro36674776 Not tainted 6.12.0-rc1-syzk RIP: 0010:x86pmuenableevent (arch/x86/events/perfevent.h:1195 arch/x86/events/core.c:1430) RSP: 0018:ffff888118009d60 EFLAGS: 00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601 FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0 Call Trace: <IRQ> amdpmuenableall (arch/x86/events/amd/core.c:760 (discriminator 2)) x86pmuenable (arch/x86/events/core.c:1360) eventschedout (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346) _perfremovefromcontext (kernel/events/core.c:2435) eventfunction (kernel/events/core.c:259) remotefunction (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1)) _flushsmpcallfunctionqueue (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540) _sysveccallfunctionsingle (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./arch/x86/include/asm/trace/irqvectors.h:99 arch/x86/kernel/smp.c:272) sysveccallfunctionsingle (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47)) </IRQ>(CVE-2025-68798)

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

mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats

Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.

One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].

Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.

[1] BUG: KASAN: slab-use-after-free in mlxswspmrstatsupdate+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrummr.c:1006 [mlxswspectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043

CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxswcore mlxswspmrstatsupdate [mlxswspectrum] Call Trace: <TASK> dumpstacklvl+0xba/0x110 printreport+0x174/0x4f5 kasanreport+0xdf/0x110 mlxswspmrstatsupdate+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrummr.c:1006 [mlxswspectrum] processonework+0x9cc/0x18e0 workerthread+0x5df/0xe40 kthread+0x3b8/0x730 retfromfork+0x3e9/0x560 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 29933: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0x8f/0xa0 mlxswspmrrouteadd+0xd8/0x4770 [mlxswspectrum] mlxswsprouterfibmreventwork+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrumrouter.c:7965 [mlxswspectrum] processonework+0x9cc/0x18e0 workerthread+0x5df/0xe40 kthread+0x3b8/0x730 retfromfork+0x3e9/0x560 retfromforkasm+0x1a/0x30

Freed by task 29933: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasansavefreeinfo+0x3b/0x70 _kasanslabfree+0x43/0x70 kfree+0x14e/0x700 mlxswspmrrouteadd+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrummr.c:444 [mlxswspectrum] mlxswsprouterfibmreventwork+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrumrouter.c:7965 [mlxswspectrum] processonework+0x9cc/0x18e0 workerthread+0x5df/0xe40 kthread+0x3b8/0x730 retfromfork+0x3e9/0x560 retfromforkasm+0x1a/0x30(CVE-2025-68800)

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

mlxsw: spectrum_router: Fix neighbour use-after-free

We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.

Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.

Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.

[1] BUG: KASAN: slab-use-after-free in mlxswspneighentryupdate+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929

CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dumpstacklvl+0x6f/0xa0 printaddressdescription.constprop.0+0x6e/0x300 printreport+0xfc/0x1fb kasanreport+0xe4/0x110 mlxswspneighentryupdate+0x2d4/0x310 mlxswsprouterrifgonesync+0x35f/0x510 mlxswsprifdestroy+0x1ea/0x730 mlxswspinetaddrportvlanevent+0xa1/0x1b0 mlxswspinetaddrlagevent+0xcc/0x130 _mlxswspinetaddrevent+0xf5/0x3c0 mlxswsprouternetdeviceevent+0x1015/0x1580 notifiercallchain+0xcc/0x150 callnetdevicenotifiersinfo+0x7e/0x100 _netdevupperdevunlink+0x10b/0x210 netdevupperdevunlink+0x79/0xa0 vrfdelslave+0x18/0x50 dosetmaster+0x146/0x7d0 dosetlink.isra.0+0x9a0/0x2880 rtnlnewlink+0x637/0xb20 rtnetlinkrcvmsg+0x6fe/0xb90 netlinkrcvskb+0x123/0x380 netlinkunicast+0x4a3/0x770 netlinksendmsg+0x75b/0xc90 _socksendmsg+0xbe/0x160 _syssendmsg+0x5b2/0x7d0 _syssendmsg+0xfd/0x180 _syssendmsg+0x124/0x1c0 dosyscall64+0xbb/0xfd0 entrySYSCALL64afterhwframe+0x4b/0x53 [...]

Allocated by task 109: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0x7b/0x90 _kmallocnoprof+0x2c1/0x790 neighalloc+0x6af/0x8f0 neighcreate+0x63/0xe90 mlxswspnexthopneighinit+0x430/0x7e0 mlxswspnexthoptypeinit+0x212/0x960 mlxswspnexthop6groupinfoinit.constprop.0+0x81f/0x1280 mlxswspnexthop6groupget+0x392/0x6a0 mlxswspfib6entrycreate+0x46a/0xfd0 mlxswsprouterfib6replace+0x1ed/0x5f0 mlxswsprouterfib6eventwork+0x10a/0x2a0 processonework+0xd57/0x1390 workerthread+0x4d6/0xd40 kthread+0x355/0x5b0 retfromfork+0x1d4/0x270 retfromforkasm+0x11/0x20

Freed by task 154: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x43/0x70 kmemcachefreebulk.part.0+0x1eb/0x5e0 kvfreercubulk+0x1f2/0x260 kfreercuwork+0x130/0x1b0 processonework+0xd57/0x1390 workerthread+0x4d6/0xd40 kthread+0x355/0x5b0 retfromfork+0x1d4/0x270 retfromforkasm+0x11/0x20

Last potentially related work creation: kasansavestack+0x30/0x50 kasanrecordauxstack+0x8c/0xa0 kvfreecallrcu+0x93/0x5b0 mlxswsprouterneigheventwork+0x67d/0x860 processonework+0xd57/0x1390 workerthread+0x4d6/0xd40 kthread+0x355/0x5b0 retfromfork+0x1d4/0x270 retfromforkasm+0x11/0x20(CVE-2025-68801)

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

fuse: fix io-uring list corruption for terminated non-committed requests

When a request is terminated before it has been committed, the request is not removed from the queue's list. This leaves a dangling list entry that leads to list corruption and use-after-free issues.

Remove the request from the queue's list for terminated non-committed requests.(CVE-2025-68805)

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

fuse: fix readahead reclaim deadlock

Commit e26ee4efbc79 ("fuse: allocate ff->releaseargs only if release is needed") skips allocating ff->releaseargs if the server does not implement open. However in doing so, fusepreparerelease() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuseevictinode() attempts to remove all folios associated with the inode from the page cache (truncateinodepages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim:

>>> stacktrace(1504735) foliowaitbitcommon (mm/filemap.c:1308:4) foliolock (./include/linux/pagemap.h:1052:3) truncateinodepagesrange (mm/truncate.c:336:10) fuseevictinode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentryunlinkinode (fs/dcache.c:412:3) _dentrykill (fs/dcache.c:615:3) shrinkkill (fs/dcache.c:1060:12) shrinkdentrylist (fs/dcache.c:1087:3) prunedcachesb (fs/dcache.c:1168:2) supercachescan (fs/super.c:221:10) doshrinkslab (mm/shrinker.c:435:9) shrinkslab (mm/shrinker.c:626:10) shrinknode (mm/vmscan.c:5951:2) shrinkzones (mm/vmscan.c:6195:3) dotrytofreepages (mm/vmscan.c:6257:3) doswappage (mm/memory.c:4136:11) handleptefault (mm/memory.c:5562:10) handlemmfault (mm/memory.c:5870:9) douseraddrfault (arch/x86/mm/fault.c:1338:10) handlepagefault (arch/x86/mm/fault.c:1481:3) excpagefault (arch/x86/mm/fault.c:1539:2) asmexcpagefault+0x22/0x27

Fix this deadlock by allocating ff->releaseargs and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fusefileput() -> fuserelease_end()).(CVE-2025-68821)

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

iavf: fix off-by-one issues in iavfconfigrss_reg()

There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.

Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40EVFQF{HKEY,HLUT}MAXINDEX which is safe since the value is the last valid index.

That commit changed the bounds to: i <= adapter->rss{key,lut}size / 4 where rss_{key,lut}_size / 4 is the number of dwords, so the last valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <= accesses one element past the end.

Fix the issues by using < instead of <=, ensuring we do not exceed the bounds.

[1] KASAN splat about rsskeysize off-by-one BUG: KASAN: slab-out-of-bounds in iavfconfigrss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63

CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavfwatchdogtask Call Trace: <TASK> dumpstacklvl+0x6f/0xb0 printreport+0x170/0x4f3 kasanreport+0xe1/0x1a0 iavfconfigrss+0x619/0x800 iavfwatchdogtask+0x2be7/0x3230 processonework+0x7fd/0x1420 workerthread+0x4d1/0xd40 kthread+0x344/0x660 retfromfork+0x249/0x320 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 63: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0x7f/0x90 _kmallocnoprof+0x246/0x6f0 iavfwatchdogtask+0x28fc/0x3230 processonework+0x7fd/0x1420 workerthread+0x4d1/0xd40 kthread+0x344/0x660 retfromfork+0x249/0x320 retfromforkasm+0x1a/0x30

The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)

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

e1000: fix OOB in e1000tbishould_accept()

In e1000tbishouldaccept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000cleanrxirq):

================================================================== BUG: KASAN: slab-out-of-bounds in e1000tbishould_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363

CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0x5a/0x74 printaddressdescription+0x7b/0x440 printreport+0x101/0x200 kasanreport+0xc1/0xf0 e1000tbishouldaccept+0x610/0x790 e1000cleanrxirq+0xa8c/0x1110 e1000clean+0xde2/0x3c10 _napipoll+0x98/0x380 netrxaction+0x491/0xa20 _dosoftirq+0x2c9/0x61d dosoftirq+0xd1/0x120 </IRQ> <TASK> _localbhenableip+0xfe/0x130 ipfinishoutput2+0x7d5/0xb00 _ipqueuexmit+0xe24/0x1ab0 _tcptransmitskb+0x1bcb/0x3340 tcpwritexmit+0x175d/0x6bd0 _tcppushpendingframes+0x7b/0x280 tcpsendmsglocked+0x2e4f/0x32d0 tcpsendmsg+0x24/0x40 sockwriteiter+0x322/0x430 vfswrite+0x56c/0xa60 ksyswrite+0xd1/0x190 dosyscall64+0x43/0x90 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: _kasankrealloc+0x131/0x1c0 krealloc+0x90/0xc0 addsysfsparam+0xcb/0x8a0 kerneladdsysfsparam+0x81/0xd4 paramsysfsbuiltin+0x138/0x1a6 paramsysfsinit+0x57/0x5b dooneinitcall+0x104/0x250 doinitcalllevel+0x102/0x132 doinitcalls+0x46/0x74 kernelinitfreeable+0x28f/0x393 kernelinit+0x14/0x1a0 retfromfork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compoundmapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000

page dumped because: kasan: bad access detected

This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:

u8 last_byte = *(data + length - 1);

Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rxbufferlen. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)

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

usb: typec: ucsi: Handle incorrect num_connectors capability

The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly.

Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.(CVE-2025-71108)

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

crypto: afalg - zero initialize memory allocated via sockkmalloc

Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.

The ACVP patches also contain two user-space interface files: algifkpp.c and algifakcipher.c. These too rely on proper initialization of their context structures.

A particular issue has been observed with the newly added 'inflight' variable introduced in afalgctx by commit:

67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")

Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, afalgalloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:

https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209

The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.(CVE-2025-71113)

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

powerpc/kexec: Enable SMT before waking offline CPUs

If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:

kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core64.c:223 kexecpreparecpus+0x1b0/0x1bc [snip] NIP kexecpreparecpus+0x1b0/0x1bc LR kexecpreparecpus+0x1a0/0x1bc Call Trace: kexecpreparecpus+0x1a0/0x1bc (unreliable) defaultmachinekexec+0x160/0x19c machinekexec+0x80/0x88 kernelkexec+0xd0/0x118 _dosysreboot+0x210/0x2c4 systemcallexception+0x124/0x320 systemcallvectored_common+0x15c/0x2ec

This occurs as addcpu() fails due to cpubootable() returning false for CPUs that fail the cpusmtthread_allowed() check or non primary threads if SMT is disabled.

Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.(CVE-2025-71119)

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

tracing: Do not register unsupported perf events

Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:

------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepointaddfunc+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvmintel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepointaddfunc+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepointproberegister+0x5d/0x90 syntheventreg+0x3c/0x60 perftraceeventinit+0x204/0x340 perftraceinit+0x85/0xd0 perftpeventinit+0x2e/0x50 perftryinitevent+0x6f/0x230 ? perfeventalloc+0x4bb/0xdc0 perfeventalloc+0x65a/0xdc0 _sesysperfeventopen+0x290/0x9f0 dosyscall64+0x93/0x7b0 ? entrySYSCALL64afterhwframe+0x76/0x7e ? tracehardirqsoff+0x53/0xc0 entrySYSCALL64after_hwframe+0x76/0x7e

Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:

# perf record -e synthetic:futexwait Error: The sysperfeventopen() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.

Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)

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

cifs: Fix memory and information leak in smb3_reconfigure()

In smb3reconfigure(), if smb3syncsessionctxpasswords() fails, the function returns immediately without freeing and erasing the newly allocated newpassword and new_password2. This causes both a memory leak and a potential information leak.

Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.(CVE-2025-71151)

Database specific

{
    "severity": "High"
}

References

Affected packages

openEuler:24.03-LTS / kernel

Package

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

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0Unknown introduced version / All previous versions are affected

Fixed

6.6.0-138.0.0.119.oe2403

Ecosystem specific

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

Database specific

source

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