The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migratetonode() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having findvma() return NULL, to then de-referenceNULL. So properly handle findvma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migratetonode mm/mempolicy.c:1090 [inline]RIP: 0010:domigratepages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: <TASK> kernelmigratepages+0x5b2/0x750 mm/mempolicy.c:1709 __dosysmigrate_pages mm/mempolicy.c:1727 [inline] __sesysmigrate_pages mm/mempolicy.c:1723 [inline] _x64sysmigratepages+0x96/0x100 mm/mempolicy.c:1723 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7fakpm@linux-foundation.org: add unlikely()

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

PCI/MSI: Handle lack of irqdomain gracefully

Alexandre observed a warning emitted from pcimsisetupmsiirqs() on a RISCV platform which does not provide PCI/MSI support:

WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pcimsisetupmsiirqs+0x2c/0x32 _pcienablemsixrange+0x30c/0x596 pcimsisetupmsiirqs+0x2c/0x32 pciallocirqvectorsaffinity+0xb8/0xe2

RISCV uses hierarchical interrupt domains and correctly does not implement the legacy fallback. The warning triggers from the legacy fallback stub.

That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent domain is associated with the device or not. There is a check for MSI-X, which has a legacy assumption. But that legacy fallback assumption is only valid when legacy support is enabled, but otherwise the check should simply return -ENOTSUPP.

Loongarch tripped over the same problem and blindly enabled legacy support without implementing the legacy fallbacks. There are weak implementations which return an error, so the problem was papered over.

Correct pcimsidomain_supports() to evaluate the legacy mode and add the missing supported check into the MSI enable path to complete it.(CVE-2024-56760)

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

NFS: fix nfsreleasefolio() to not deadlock via kcompactd writeback

Add PFKCOMPACTD flag and currentiskcompactd() helper to check for it so nfsreleasefolio() can skip calling nfswb_folio() from kcompactd.

Otherwise NFS can deadlock waiting for kcompactd enduced writeback which recurses back to NFS (which triggers writeback to NFSD via NFS loopback mount on the same host, NFSD blocks waiting for XFS's call to __filemapgetfolio):

6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.

{--- [58] "kcompactd0" [<0>] foliowaitbit+0xe8/0x200 [<0>] foliowaitwriteback+0x2b/0x80 [<0>] nfswbfolio+0x80/0x1b0 [nfs] [<0>] nfsreleasefolio+0x68/0x130 [nfs] [<0>] splithugepagetolisttoorder+0x362/0x840 [<0>] migratepagesbatch+0x43d/0xb90 [<0>] migratepagessync+0x9a/0x240 [<0>] migratepages+0x93c/0x9f0 [<0>] compactzone+0x8e2/0x1030 [<0>] compactnode+0xdb/0x120 [<0>] kcompactd+0x121/0x2e0 [<0>] kthread+0xcf/0x100 [<0>] retfromfork+0x31/0x40 [<0>] retfromforkasm+0x1a/0x30 ---}

[(CVE-2025-21908)

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

hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio

Commit b15c87263a69 ("hwpoison, memoryhotplug: allow hwpoisoned pages to be offlined) add page poison checks in domigraterange in order to make offline hwpoisoned page possible by introducing isolatelrupage and trytounmap for hwpoisoned page. However folio lock must be held before calling tryto_unmap. Add it to fix this problem.

Warning will be produced if folio is not locked during unmap:

------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : trytounmapone+0xb08/0xd3c lr : trytounmapone+0x3dc/0xd3c Call trace: trytounmapone+0xb08/0xd3c (P) trytounmapone+0x3dc/0xd3c (L) rmapwalkanon+0xdc/0x1f8 rmapwalk+0x3c/0x58 trytounmap+0x88/0x90 unmappoisonedfolio+0x30/0xa8 domigraterange+0x4a0/0x568 offlinepages+0x5a4/0x670 memoryblockaction+0x17c/0x374 memorysubsysoffline+0x3c/0x78 deviceoffline+0xa4/0xd0 statestore+0x8c/0xf0 devattrstore+0x18/0x2c sysfskfwrite+0x44/0x54 kernfsfopwriteiter+0x118/0x1a8 vfswrite+0x3a8/0x4bc ksys_write+0x6c/0xf8 _arm64syswrite+0x1c/0x28 invokesyscall+0x44/0x100 el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x30/0xd0 el0t64synchandler+0xc8/0xcc el0t64sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---(CVE-2025-21931)

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

net/mlx5: Bridge, fix the crash caused by LAG state check

When removing LAG device from bridge, NETDEVCHANGEUPPER event is triggered. Driver finds the lower devices (PFs) to flush all the offloaded entries. And mlx5lagissharedfdb is checked, it returns false if one of PF is unloaded. In such case, mlx5eswbridgelagrepget() and its caller return NULL, instead of the alive PF, and the flush is skipped.

Besides, the bridge fdb entry's lastuse is updated in mlx5 bridge event handler. But this SWITCHDEVFDBADDTOBRIDGE event can be ignored in this case because the upper interface for bond is deleted, and the entry will never be aged because lastuse is never updated.

To make things worse, as the entry is alive, mlx5 bridge workqueue keeps sending that event, which is then handled by kernel bridge notifier. It causes the following crash when accessing the passed bond netdev which is already destroyed.

To fix this issue, remove such checks. LAG state is already checked in commit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when adding bond to bridge"), driver still need to skip offload if LAG becomes invalid state after initialization.

Oops: stack segment: 0000 [#1] SMP CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0mlnx #1 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5bridgewq mlx5eswbridgeupdatework [mlx5core] RIP: 0010:brswitchdevevent+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __diebody+0x1a/0x60 ? die+0x38/0x60 ? dotrap+0x10b/0x120 ? doerrortrap+0x64/0xa0 ? excstacksegment+0x33/0x50 ? asmexcstacksegment+0x22/0x30 ? brswitchdevevent+0x2c/0x110 [bridge] ? schedbalancenewidle.isra.149+0x248/0x390 notifiercallchain+0x4b/0xa0 atomicnotifiercallchain+0x16/0x20 mlx5eswbridgeupdate+0xec/0x170 [mlx5core] mlx5eswbridgeupdatework+0x19/0x40 [mlx5core] processscheduledworks+0x81/0x390 workerthread+0x106/0x250 ? bhworker+0x110/0x110 kthread+0xb7/0xe0 ? kthreadpark+0x80/0x80 retfromfork+0x2d/0x50 ? kthreadpark+0x80/0x80 retfromforkasm+0x11/0x20 </TASK>(CVE-2025-21970)

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

netsched: Prevent creation of classes with TCH_ROOT

The function qdisctreereducebacklog() uses TCHROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TCH_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho.

Prevent the creation of any Qdisc class with classid TCHROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal.(CVE-2025-21971)

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

sched: address a potential NULL pointer dereference in the GRED scheduler.

If kzalloc in gredinit returns a NULL pointer, the code follows the error handling path, invoking greddestroy. This, in turn, calls gred_offload, where memset could receive a NULL pointer as input, potentially leading to a kernel crash.

When table->opt is NULL in gredinit(), gredchangetabledef() is not called yet, so it is not necessary to call ->ndosetuptc() in gred_offload().(CVE-2025-21980)

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

ice: fix memory leak in aRFS after reset

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

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

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

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

net: switchdev: Convert blocking notification chain to a raw one

A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event.

In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1].

Specifically, this can happen when the bridge driver processes a SWITCHDEVBRPORTUNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdevdeferredprocess().

Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in callswitchdevblocking_notifiers() to make sure this is not violated in the future.

Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block.

6.14.0-rc4-custom-g079270089484 #1 Not tainted

ip/52731 is trying to acquire lock: ffffffff850918d8 ((switchdevblockingnotifchain).rwsem){++++}-{4:4}, at: blockingnotifiercallchain+0x58/0xa0

but task is already holding lock: ffffffff850918d8 ((switchdevblockingnotifchain).rwsem){++++}-{4:4}, at: blockingnotifiercallchain+0x58/0xa0

other info that might help us debug this: Possible unsafe locking scenario:

CPU0

lock((switchdevblockingnotifchain).rwsem); lock((switchdevblockingnotifchain).rwsem);

*** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by ip/52731: #0: ffffffff84f795b0 (rtnlmutex){+.+.}-{4:4}, at: rtnlnewlink+0x727/0x1dc0 #1: ffffffff8731f628 (&net->rtnlmutex){+.+.}-{4:4}, at: rtnlnewlink+0x790/0x1dc0 #2: ffffffff850918d8 ((switchdevblockingnotifchain).rwsem){++++}-{4:4}, at: blockingnotifiercallchain+0x58/0xa0

stack backtrace: ... ? __pfxdownread+0x10/0x10 ? __pfxmarklock+0x10/0x10 ? __pfxswitchdevportattrset_deferred+0x10/0x10 blockingnotifiercallchain+0x58/0xa0 switchdevportattrnotify.constprop.0+0xb3/0x1b0 ? __pfxswitchdevportattrnotify.constprop.0+0x10/0x10 ? markheldlocks+0x94/0xe0 ? switchdevdeferredprocess+0x11a/0x340 switchdevportattrsetdeferred+0x27/0xd0 switchdevdeferredprocess+0x164/0x340 brswitchdevportunoffload+0xc8/0x100 [bridge] brswitchdevblockingevent+0x29f/0x580 [bridge] notifiercallchain+0xa2/0x440 blockingnotifiercallchain+0x6e/0xa0 switchdevbridgeportunoffload+0xde/0x1a0 ...(CVE-2025-21986)

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

drm/sched: Fix fence reference count leak

The last_scheduled fence leaks when an entity is being killed and adding the cleanup callback fails.

Decrement the reference count of prev when dmafenceadd_callback() fails, ensuring proper balance.

phasta: add git tag info for stable kernel

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

accel/qaic: Fix integer overflow in qaicvalidatereq()

These are u64 variables that come from the user via qaicattachsliceboioctl(). Use checkaddoverflow() to ensure that the math doesn't have an integer wrapping bug.(CVE-2025-22001)

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

regulator: dummy: force synchronous probing

Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack:

anatopregulatorprobe() devmregulatorregister() regulatorregister() regulatorresolvesupply() kobjectget()

By placing some extra BUGON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummyregulator_rdev' is still NULL).

In the JTAG debugger I can see that dummyregulatorprobe() and anatopregulatorprobe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously.(CVE-2025-22009)

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

spufs: fix a leak in spufscreatecontext()

Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor.(CVE-2025-22071)

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

Revert "smb: client: fix TCP timers deadlock after rmmod"

This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.

Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is mentioned as CVE-2024-54680, but is actually did not fix anything; The issue can be reproduced on top of it. [0]

Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") and introduced a real issue by reviving the kernel TCP socket.

When a reconnect happens for a CIFS connection, the socket state transitions to FINWAIT1. Then, inetcskclearxmittimerssync() in tcpclose() stops all timers for the socket.

If an incoming FIN packet is lost, the socket will stay at FINWAIT1 forever, and such sockets could be leaked up to net.ipv4.tcpmaxorphans.

Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality.

I warned about this privately by pointing out the exact report [1], but the bogus fix was finally merged.

So, we should not stop the timers to finally kill the connection on our side in that case, meaning we must not use a kernel socket for TCP whose sk->sknetrefcnt is 0.

The kernel socket does not have a reference to its netns to make it possible to tear down netns without cleaning up every resource in it.

For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died.

However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection.

If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free.

Actually, we have seen so many similar issues and converted such sockets to have a reference to netns.

That's why I converted the CIFS client socket to have a reference to netns (sk->sknetrefcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but is in-scope and right fix.

Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in socklockinitclassand_name(). [2]

For a while, let's revert the bogus fix.

Note that now we can use sknetrefcnt_upgrade() for the socket conversion, but I'll do so later separately to make backport easy.(CVE-2025-22077)

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

watch_queue: fix pipe accounting mismatch

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

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

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

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

media: venus: hfi_parser: add check to avoid out of bound access

There is a possibility that initcodecs is invoked multiple times during manipulated payload from video firmware. In such case, if codecscount can get incremented to value more than MAXCODECNUM, there can be OOB access. Reset the count so that it always starts from beginning.(CVE-2025-23157)

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

jfs: add sanity check for agwidth in dbMount

The width in dmapctl of the AG is zero, it trigger a divide error when calculating the control page level in dbAllocAG.

To avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)

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

iommu/mediatek: Fix NULL pointer deference in mtkiommudevice_group

Currently, mtkiommu calls during probe iommudeviceregister before the hwlist from driver data is initialized. Since iommu probing issue fix, it leads to NULL pointer dereference in mtkiommudevicegroup when hwlist is accessed with listfirstentry (not null safe).

So, change the call order to ensure iommudeviceregister is called after the driver data are initialized.(CVE-2025-37748)

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

drm/amd/pm: Prevent division by zero

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

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

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

drm/amd/pm: Prevent division by zero

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

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

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

drm/amd/pm: Prevent division by zero

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

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

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

drm/amd/pm: Prevent division by zero

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

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

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

ksmbd: Fix dangling pointer in krb_authenticate

krbauthenticate frees sess->user and does not set the pointer to NULL. It calls ksmbdkrb5authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2sesssetup, which calls krbauthenticate, will be accessing free'd memory when it later uses sess->user.(CVE-2025-37778)

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

ASoC: Intel: avs: Fix null-ptr-deref in avscomponentprobe()

devmkasprintf() returns NULL when memory allocation fails. Currently, avscomponent_probe() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37793)

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

sound/virtio: Fix cancelsync warnings on uninitialized workstructs

Betty reported hitting the following warning:

[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] _cancelworksync+0xac/0xfc [ 8.713570][ T221] cancelworksync+0x24/0x34 [ 8.713667][ T221] virtsndremove+0xa8/0xf8 [virtiosnd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsndprobe+0x48c/0x664 [virtiosnd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtiodevprobe+0x28c/0x390 [ 8.714139][ T221] reallyprobe+0x1bc/0x4c8 ...

It seems we're hitting the error path in virtsndprobe(), which triggers a virtsndremove() which iterates over the substreams calling cancelworksync() on the elapsedperiod workstruct.

Looking at the code, from earlier in: virtsndprobe()->virtsndbuilddevs()->virtsndpcmparsecfg()

We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsndctlqueryinfo() fails, we will exit without having initialized the elapsedperiod work_struct.

When that error path unwinds we then call virtsndremove() which as long as the substreams array is allocated, will iterate through calling cancelwork_sync() on the uninitialized work struct hitting this warning.

Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data.

Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing.

Feedback or thoughts would be appreciated!(CVE-2025-37805)

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

misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration

Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generichandleirq.

A previous fix patch was submitted where 'generichandleirq' was replaced with 'handlenestedirq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handlenestedirq with the mapped IRQ number, leads to a failure in locating the registered handler.(CVE-2025-37815)

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

cpufreq: apple-soc: Fix null-ptr-deref in applesoccpufreqgetrate()

cpufreqcpugetraw() can return NULL when the target CPU is not present in the policy->cpus mask. applesoccpufreqget_rate() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37831)

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

cifs: avoid NULL pointer dereference in dbg call

cifsserverdbg() implies server to be non-NULL so move call under condition to avoid NULL pointer dereference.

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

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

drm/amdkfd: debugfs hang_hws skip GPU with MES

debugfs hanghws is used by GPU reset test with HWS, for MES this crash the kernel with NULL pointer access because dqm->packetmgr is not setup for MES path.

Skip GPU with MES for now, MES hang_hws debugfs interface will be supported later.(CVE-2025-37853)

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

usb: gadget: aspeed: Add NULL pointer check in astvhubinit_dev()

The variable d->name, returned by devmkasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in iceptp.c").

This issue is found by our static analysis tool(CVE-2025-37881)

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

ASoC: ops: Consistently treat platform_max as control value

This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in sndsocput_volsw() by +min"), and makes some additional related updates.

There are two ways the platformmax could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as sndsoclimitvolume() also used the register interpretation. However, even then most of the other usages treated platformmax as a control value, and sndsoclimitvolume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating sndsocputvolsw() back to the control interpretation, and fixing sndsocinfovolswrange(). The control interpretation makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platformmax.

Finally, also add some comments to the socmixercontrol struct to hopefully avoid further patches switching between the two approaches.(CVE-2025-37889)

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

firmware: arm_scmi: Balance device refcount when destroying devices

Using devicefindchild() to lookup the proper SCMI device to destroy causes an unbalance in device refcount, since devicefindchild() calls an implicit get_device(): this, in turns, inhibits the call of the provided release methods upon devices destruction.

As a consequence, one of the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the drivers subsystem core.

KMemleak detects this situation since loading/unloding some SCMI driver causes related devices to be created/destroyed without calling any device_release method.

unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloccachenoprof+0x2dc/0x398 deviceadd+0x954/0x12d0 deviceregister+0x28/0x40 _scmidevicecreate.part.0+0x1bc/0x380 scmidevicecreate+0x2d0/0x390 scmicreateprotocoldevices+0x74/0xf8 scmidevicerequestnotifier+0x1f8/0x2a8 notifiercallchain+0x110/0x3b0 blockingnotifiercallchain+0x70/0xb0 scmidriverregister+0x350/0x7f0 0xffff80000a3b3038 dooneinitcall+0x12c/0x730 doinitmodule+0x1dc/0x640 loadmodule+0x4b20/0x5b70 initmodulefromfile+0xec/0x158

$ ./scripts/faddr2line ./vmlinux deviceadd+0x954/0x12d0 deviceadd+0x954/0x12d0: kmallocnoprof at include/linux/slab.h:901 (inlined by) kzallocnoprof at include/linux/slab.h:1037 (inlined by) deviceprivateinit at drivers/base/core.c:3510 (inlined by) device_add at drivers/base/core.c:3561

Balance device refcount by issuing a putdevice() on devices found via devicefind_child().(CVE-2025-37905)

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

Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()

A NULL pointer dereference can occur in skb_dequeue() when processing a QCA firmware crash dump on WCN7851 (0489:e0f3).

[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)

[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 93.672517] Workqueue: hci0 hcidevcdrx [bluetooth] [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80

The issue stems from handledumppktqca() returning 0 even when a dump packet is successfully processed. This is because it incorrectly forwards the return value of hcidevcdinit() (which returns 0 on success). As a result, the caller (btusbrecvaclqca() or btusbrecvevtqca()) assumes the packet was not handled and passes it to hcirecv_frame(), leading to premature kfree() of the skb.

Later, hcidevcdrx() attempts to dequeue the same skb from the dump queue, resulting in a NULL pointer dereference.

Fix this by: 1. Making handledumppkt_qca() return 0 on success and negative errno on failure, consistent with kernel conventions. 2. Splitting dump packet detection into separate functions for ACL and event packets for better structure and readability.

This ensures dump packets are properly identified and consumed, avoiding double handling and preventing NULL pointer access.(CVE-2025-37918)

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

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

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

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

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

usb: typec: ucsi: displayport: Fix deadlock

This patch introduces the ucsiconmutexlock / ucsiconmutexunlock functions to the UCSI driver. ucsiconmutexlock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsidisplayportremovepartner holds con->mutex waiting for dpaltmodework to complete while dpaltmodework attempts to acquire it.(CVE-2025-37967)

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

dmaengine: idxd: Refactor remove call with idxd_cleanup() helper

The idxdcleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxdcleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs.(CVE-2025-38014)

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

vxlan: Annotate FDB data races

The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2].

Suppress these reports by annotating these accesses using READONCE() / WRITEONCE().

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

write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlanxmit+0xb29/0x2380 devhardstartxmit+0x84/0x2f0 __devqueuexmit+0x45a/0x1650 packetxmit+0x100/0x150 packetsendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64syssendto+0x76/0x90 x64syscall+0x14e8/0x1c00 dosyscall64+0x9e/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlanxmit+0xadf/0x2380 devhardstartxmit+0x84/0x2f0 __devqueuexmit+0x45a/0x1650 packetxmit+0x100/0x150 packetsendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64syssendto+0x76/0x90 x64syscall+0x14e8/0x1c00 dosyscall64+0x9e/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f

value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f

Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

[2] #!/bin/bash

set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan

ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &(CVE-2025-38037)

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

firmware: armffa: Set dmamask for ffa devices

Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning:

WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dmaallocattrs+0xe0/0x124(CVE-2025-38043)

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

smb: client: Fix use-after-free in cifsfilldirent

There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning.

================================================================== BUG: KASAN: slab-use-after-free in cifsfilldirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975

CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xce/0x640 kasanreport+0xb8/0xf0 cifsfilldirent+0xb03/0xb60 [cifs] cifsreaddir+0x12cb/0x3190 [cifs] iteratedir+0x1a1/0x520 _x64sysgetdents+0x134/0x220 dosyscall64+0x4b/0x110 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff 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 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIGRAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK>

Allocated by task 408: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 _kasanslaballoc+0x6e/0x70 kmemcacheallocnoprof+0x117/0x3d0 mempoolallocnoprof+0xf2/0x2c0 cifsbufget+0x36/0x80 [cifs] allocatebuffers+0x1d2/0x330 [cifs] cifsdemultiplexthread+0x22b/0x2690 [cifs] kthread+0x394/0x720 retfromfork+0x34/0x70 retfromforkasm+0x1a/0x30

Freed by task 342979: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasansavefree_info+0x3b/0x60 __kasanslabfree+0x37/0x50 kmemcachefree+0x2b8/0x500 cifsbufrelease+0x3c/0x70 [cifs] cifsreaddir+0x1c97/0x3190 [cifs] iteratedir+0x1a1/0x520 __x64sysgetdents64+0x134/0x220 dosyscall64+0x4b/0x110 entrySYSCALL64afterhwframe+0x76/0x7e

The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) pagetype: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================

POC is available in the link [1].

The problem triggering process is as follows:

Process 1 Process 2

---truncated---(CVE-2025-38051)

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

virtio: break and reset virtio devices on device_shutdown()

Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory accesses during the hang.

Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected
Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected
...

It was traced down to virtio-console. Kexec works fine if virtio-console is not in use.

The issue is that virtio-console continues to write to the MMIO even after underlying virtio-pci device is reset.

Additionally, Eric noticed that IOMMUs are reset before devices, if devices are not reset on shutdown they continue to poke at guest memory and get errors from the IOMMU. Some devices get wedged then.

The problem can be solved by breaking all virtio devices on virtio bus shutdown, then resetting them.(CVE-2025-38064)

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

ACPI: CPPC: Fix NULL pointer dereference when nosmp is used

With nosmp in cmdline, other CPUs are not brought up, leaving their cpcdescptr NULL. CPU0's iteration via foreachpossible_cpu() dereferences these NULL pointers, causing panic.

Panic backtrace:

[ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8 ... [ 0.403255] [<ffffffff809a5818>] cppcallowfast_switch+0x6a/0xd4 ... Kernel panic - not syncing: Attempted to kill init!

rjw: New subject

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

gve: add missing NULL check for gveallocpending_packet() in TX DQO

gveallocpendingpacket() can return NULL, but gvetxaddskb_dqo() did not check for this case before dereferencing the returned pointer.

Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails.

This improves robustness in low-memory scenarios.(CVE-2025-38122)

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

net: wwan: t7xx: Fix napi rx poll issue

When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic.

BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:devgroreceive+0x3a/0x620 [...] Call Trace: <IRQ> ? __diebody+0x68/0xb0 ? pagefaultoops+0x379/0x3e0 ? excpagefault+0x4f/0xa0 ? asmexcpagefault+0x22/0x30 ? _pfxt7xxccmnirecvskb+0x10/0x10 [mtkt7xx (HASH:1400 7)] ? devgroreceive+0x3a/0x620 napigroreceive+0xad/0x170 t7xxccmnirecvskb+0x48/0x70 [mtkt7xx (HASH:1400 7)] t7xxdpmaifnapirxpoll+0x590/0x800 [mtkt7xx (HASH:1400 7)] netrxaction+0x103/0x470 irqexitrcu+0x13a/0x310 sysvecapictimerinterrupt+0x56/0x90 </IRQ>(CVE-2025-38123)

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

coresight: prevent deactivate active config while enabling the config

While enable active config via cscfgcsdevenableactiveconfig(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario:

CPU0 CPU1 (sysfs enable) load module cscfgloadconfigsets() activate config. // sysfs (sysactivecnt == 1) ... cscfgcsdevenableactiveconfig() lock(csdev->cscfgcsdevlock) // here load config activate by CPU1 unlock(csdev->cscfgcsdev_lock)

                                          deactivate config // sysfs
                                          (sys_activec_cnt == 0)
                                          cscfg_unload_config_sets()
                                          unload module

// access to configdesc which freed // while unloading module. cscfgcsdevenableconfig

To address this, use cscfgconfigdesc's activecnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when configactive_cnt == 0.(CVE-2025-38131)

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

net: phy: mscc: Fix memory leak when using one step timestamping

Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping.(CVE-2025-38148)

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

RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction

Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure.

Now properly rollback the object to its original state upon such failure.

In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcountt: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcountwarnsaturate+0xf4/0x148 Modules linked in: rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) rfkill mlx5core(OE) mlxdevm(OE) ibuverbs(OE) ibcore(OE) psample mlxfw(OE) mlxcompat(OE) macsec tls pcihypervintf sunrpc vfat fat virtionet netfailover failover fuse loop nfnetlink vsockloopback vmwvsockvirtiotransportcommon vmwvsockvmcitransport vmwvmci vsock xfs crct10difce ghashce sha2ce sha256arm64 sha1ce virtioconsole virtiogpu virtioblk virtiodmabuf virtiommio dmmirror dmregionhash dmlog dmmod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcountwarnsaturate+0xf4/0x148 lr : refcountwarnsaturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcountwarnsaturate+0xf4/0x148 mlx5coreputrsc+0x88/0xa0 [mlx5ib] mlx5coredestroyrqtracked+0x64/0x98 [mlx5ib] mlx5ibdestroywq+0x34/0x80 [mlx5ib] ibdestroywquser+0x30/0xc0 [ibcore] uverbsfreewq+0x28/0x58 [ibuverbs] destroyhwidruobject+0x34/0x78 [ibuverbs] uverbsdestroyuobject+0x48/0x240 [ibuverbs] __uverbscleanupufile+0xd4/0x1a8 [ibuverbs] uverbsdestroyufilehw+0x48/0x120 [ibuverbs] ibuverbsclose+0x2c/0x100 [ibuverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 _arm64sysclose+0x40/0x90 invokesyscall.constprop.0+0x74/0xd0 doel0svc+0x48/0xe8 el0svc+0x44/0x1d0 el0t64synchandler+0x120/0x130 el0t64sync+0x1a4/0x1a8(CVE-2025-38161)

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

net: lan743x: fix potential out-of-bounds write in lan743xptpioeventclock_get()

Before calling lan743xptpioeventclockget(), the 'channel' value is checked against the maximum value of PCI11X1XPTPIOMAXCHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTPINT_STS) specifications.

However, lan743xptpioeventclockget() writes to ptp->extts[] with only LAN743XPTPNEXTTS(4) elements, using channel as an index:

lan743x_ptp_io_event_clock_get(..., u8 channel,...)
{
    ...
    /* Update Local timestamp */
    extts = &ptp->extts[channel];
    extts->ts.tv_sec = sec;
    ...
}

To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743XPTPN_EXTTS to 8.

Detected using the static analysis tool - Svace.(CVE-2025-38183)

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

netsched: schsfq: reject invalid perturb period

Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch.

We want to make sure ctl->perturb_period * HZ will not overflow and is positive.

tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period.

tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period.

tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0(CVE-2025-38193)

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

jffs2: check that raw node were preallocated before writing summary

Syzkaller detected a kernel bug in jffs2linknoderef, caused by fault injection in jffs2preallocrawnoderefs. jffs2sumwritesumnode doesn't check return value of jffs2preallocrawnoderefs and simply lets any error propagate into jffs2sumwritedata, which eventually calls jffs2linknoderef in order to link the summary to an expectedly allocated node.

kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2linknoderef+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace: <TASK> jffs2sumwritedata fs/jffs2/summary.c:841 [inline] jffs2sumwritesumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874 jffs2doreservespace+0xa18/0xd60 fs/jffs2/nodemgmt.c:388 jffs2reservespace+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197 jffs2writeinoderange+0x246/0xb50 fs/jffs2/write.c:362 jffs2writeend+0x726/0x15d0 fs/jffs2/file.c:301 genericperform_write+0x314/0x5d0 mm/filemap.c:3856 __genericfilewriteiter+0x2ae/0x4d0 mm/filemap.c:3973 genericfilewriteiter+0xe3/0x350 mm/filemap.c:4005 callwriteiter include/linux/fs.h:2265 [inline] doiterreadvwritev+0x20f/0x3c0 fs/readwrite.c:735 doiterwrite+0x186/0x710 fs/readwrite.c:861 vfsiterwrite+0x70/0xa0 fs/readwrite.c:902 iterfilesplicewrite+0x73b/0xc90 fs/splice.c:685 dosplicefrom fs/splice.c:763 [inline] directspliceactor+0x10c/0x170 fs/splice.c:950 splicedirecttoactor+0x337/0xa10 fs/splice.c:896 dosplicedirect+0x1a9/0x280 fs/splice.c:1002 dosendfile+0xb13/0x12c0 fs/readwrite.c:1255 __dosyssendfile64 fs/read_write.c:1323 [inline] __sesyssendfile64 fs/read_write.c:1309 [inline] _x64syssendfile64+0x1cf/0x210 fs/readwrite.c:1309 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8

Fix this issue by checking return value of jffs2preallocrawnoderefs before calling jffs2sumwrite_data.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38194)

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

mm/shmem, swap: fix softlockup with mTHP swapin

Following softlockup can be easily reproduced on my test machine with:

echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled swapon /dev/zram0 # zram0 is a 48G swap device mkdir -p /sys/fs/cgroup/memory/test echo 1G > /sys/fs/cgroup/test/memory.max echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs while true; do dd if=/dev/zero of=/tmp/test.img bs=1M count=5120 cat /tmp/test.img > /dev/null rm /tmp/test.img done

Then after a while: watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787] Modules linked in: zram virtiofs CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)· Tainted: [L]=SOFTLOCKUP Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 RIP: 0010:mpolsharedpolicylookup+0xd/0x70 Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202 RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001 RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> shmemallocfolio+0x31/0xc0 shmemswapinfolio+0x309/0xcf0 ? filemapgetentry+0x117/0x1e0 ? xasload+0xd/0xb0 ? filemapgetentry+0x101/0x1e0 shmemgetfoliogfp+0x2ed/0x5b0 shmemfilereaditer+0x7f/0x2e0 vfsread+0x252/0x330 ksysread+0x68/0xf0 dosyscall64+0x4c/0x1c0 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f03f9a46991 Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003 RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000 </TASK>

The reason is simple, readahead brought some order 0 folio in swap cache, and the swapin mTHP folio being allocated is in conflict with it, so swapcacheprepare fails and causes shmemswapallocfolio to return -EEXIST, and shmem simply retries again and again causing this loop.

Fix it by applying a similar fix for anon mTHP swapin.

The performance change is very slight, time of swapin 10g zero folios with shmem (test for 12 times): Before: 2.47s After: 2.48s

[(CVE-2025-38241)

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

lib/groupcpus: fix NULL pointer dereference from groupcpus_evenly()

While testing nullblk with configfs, echo 0 > pollqueues will trigger following panic:

BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Call Trace: <TASK> __groupcpusevenly+0x822/0x8c0 groupcpusevenly+0x2d9/0x490 blk_mqmapqueues+0x1e/0x110 nullmapqueues+0xc9/0x170 [nullblk] blkmqupdatequeuemap+0xdb/0x160 blkmqupdatenrhwqueues+0x22b/0x560 nullbupdatenrhwqueues+0x71/0xf0 [nullblk] nullbdevicepollqueuesstore+0xa4/0x130 [nullblk] configfswriteiter+0x109/0x1d0 vfswrite+0x26e/0x6f0 ksyswrite+0x79/0x180 __x64syswrite+0x1d/0x30 x64syscall+0x45c4/0x45f0 dosyscall64+0xa5/0x240 entrySYSCALL64afterhwframe+0x76/0x7e

Root cause is that numgrps is set to 0, and ZEROSIZEPTR is returned from kcalloc(), and later ZEROSIZEPTR will be deferenced.

Fix the problem by checking numgrps first in groupcpusevenly(), and return NULL directly if numgrps is zero.

[(CVE-2025-38255)

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

Bluetooth: Fix NULL pointer deference on eirgetservice_data

The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIRSERVICEDATA.(CVE-2025-38304)

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

ASoC: Intel: avs: Verify content returned by parseintarray()

The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref.(CVE-2025-38307)

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

smb: Log an error when closeallcached_dirs fails

Under low-memory conditions, closeallcached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a "Dentry still in use" error, so add an error message that makes it clear this is what happened:

[ 495.281119] CIFS: VFS: \otters.example.com\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]------------ [ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs] [ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0

Also, bail out of looping through all tcons as soon as a single allocation fails, since we're already in trouble, and kmalloc() attempts for subseqeuent tcons are likely to fail just like the first one did.(CVE-2025-38321)

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

ACPICA: fix acpi parse and parseext cache leaks

ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5

I'm Seunghun Han, and I work for National Security Research Institute of South Korea.

I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases.

Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added OSI(Module Device) [ 0.353182] ACPI: Added OSI(Processor Device) [ 0.353182] ACPI: Added OSI(3.0 SCP Extensions) [ 0.353182] ACPI: Added OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmemcachedestroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmbh virtualbox/virtualbox, BIOS virtualbox 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dumpstack+0x5c/0x81 [ 0.362591] ? kmemcachedestroy+0x1aa/0x1c0 [ 0.362944] ? acpisleepprocinit+0x27/0x27 [ 0.363296] ? acpiosdeletecache+0xa/0x10 [ 0.363646] ? acpiutdeletecaches+0x6d/0x7b [ 0.364000] ? acpiterminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? _classcreate+0x4c/0x80 [ 0.364000] ? videosetup+0x7f/0x7f [ 0.364000] ? acpisleepprocinit+0x27/0x27 [ 0.364000] ? dooneinitcall+0x4e/0x1a0 [ 0.364000] ? kernelinitfreeable+0x189/0x20a [ 0.364000] ? restinit+0xc0/0xc0 [ 0.364000] ? kernelinit+0xa/0x100 [ 0.364000] ? retfromfork+0x25/0x30

I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size.

I finally found “Acpi-Parse” cache and “Acpi-parseext” cache were leaked using SLABNEVERMERGE flag in kmemcache_create() function.

Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added OSI(Module Device) [ 0.360101] ACPI: Added OSI(Processor Device) [ 0.360101] ACPI: Added OSI(3.0 SCP Extensions) [ 0.361043] ACPI: Added OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmemcachedestroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmbh virtualbox/virtualbox, BIOS virtualbox 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dumpstack+0x5c/0x81 [ 0.372000] ? kmemcachedestroy+0x1aa/0x1c0 [ 0.372000] ? acpisleepprocinit+0x27/0x27 [ 0.372000] ? acpiosdeletecache+0xa/0x10 [ 0.372000] ? acpiutdeletecaches+0x56/0x7b [ 0.372000] ? acpiterminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __classcreate+0x4c/0x80 [ 0.372000] ? videosetup+0x7f/0x7f [ 0.372000] ? acpisleepprocinit+0x27/0x27 [ 0.372000] ? dooneinitcall+0x4e/0x1a0 [ 0.372000] ? kernelinitfreeable+0x189/0x20a [ 0.372000] ? restinit+0xc0/0xc0 [ 0.372000] ? kernelinit+0xa/0x100 [ 0.372000] ? retfromfork+0x25/0x30 [ 0.388039] kmemcachedestroy Acpi-parseext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmbh virtualbox/virtualbox, BIOS virtualbox 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dumpstack+0x5c/0x81 [ 0.392000] ? kmemcachedestroy+0x1aa/0x1c0 [ 0.392000] ? acpisleepprocinit+0x27/0x27 [ 0.392000] ? acpiosdeletecache+0xa/0x10 [ 0.392000] ? acpiutdeletecaches+0x6d/0x7b [ 0.392000] ? acpiterminate+0xa/0x14 [ 0.392000] ? acpiinit+0x2af/0x3 ---truncated---(CVE-2025-38344)

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

mapletree: fix MASTATEPREALLOC flag in maspreallocate()

Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through masnodecountgfp(), but the allocations will not happen if the MASTATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations.

The MASTATEPREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption.

User visible effect of this flaw is a WARNON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmapregion() caused by drivers altering the vma flags (which happens in v6.6, at least)(CVE-2025-38364)

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

vsock: Fix transport_* TOCTOU

Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer.

This also takes care of an insecure call in vsockuselocal_transport(); add a lockdep assert.

BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsockassigntransport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64sysconnect+0x6e/0xc0 dosyscall64+0x92/0x1c0 entrySYSCALL64afterhwframe+0x4b/0x53(CVE-2025-38461)

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

vsock: Fix transport_{g2h,h2g} TOCTOU

vsockfindcid() and vsockdevdoioctl() may race with module unload. transport{g2h,h2g} may become NULL after the NULL check.

Introduce vsocktransportlocal_cid() to protect from a potential null-ptr-deref.

KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsockfindcid+0x47/0x90 Call Trace: __vsockbind+0x4b2/0x720 vsockbind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64sysbind+0x6e/0xc0 dosyscall64+0x92/0x1c0 entrySYSCALL64afterhwframe+0x4b/0x53

KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsockdevdo_ioctl.isra.0+0x58/0xf0 Call Trace: __x64sysioctl+0x12d/0x190 dosyscall64+0x92/0x1c0 entrySYSCALL64afterhwframe+0x4b/0x53(CVE-2025-38462)

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

smb: client: fix use-after-free in crypt_message when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:

cryptmessage() // Allocate the creq buffer containing the req creq = smb2getaeadreq(..., &req);

// Async encryption returns -EINPROGRESS immediately
rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);

// Free creq while async operation is still in progress
kvfree_sensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for performance. When cryptoaeadencrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without cryptowaitreq(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.

The issue occurs because cryptoallocaead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTOALGASYNC in the mask, async implementations can be selected.

Fix by restoring the async crypto handling: - DECLARECRYPTOWAIT(wait) for completion tracking - aeadrequestsetcallback() for async completion notification - cryptowait_req() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.(CVE-2025-38488)

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

cloneprivatemnt(): make sure that caller has CAPSYSADMIN in the right userns

What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to.

cloneprivatemnt() checks the former, but not the latter.

There's a number of rather confusing CAPSYSADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of cloneprivatemnt() they usually, but not always end up covering the missing check mentioned above.(CVE-2025-38499)

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

mptcp: plug races between subflow fail and subflow creation

We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger.

The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock.

The socket fallback makes such flag true, and also receiving or sending an MP_FAIL option.

The field 'allowinfinitefallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.(CVE-2025-38552)

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

ksmbd: use aeadrequestfree to match aeadrequestalloc

Use aeadrequestfree() instead of kfree() to properly free memory allocated by aeadrequestalloc(). This ensures sensitive crypto data is zeroed before being freed.(CVE-2025-38575)

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

PM / devfreq: Check governor before using governor->name

Commit 96ffcdf239de ("PM / devfreq: Remove redundant governorname from struct devfreq") removes governorname and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name.(CVE-2025-38609)

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnet_list.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ct_general);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.(CVE-2025-38721)

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

scsi: qla4xxx: Prevent a potential error pointer dereference

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

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

tls: fix handling of zero-length records on the rx_list

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there.

Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.(CVE-2025-39682)

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

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

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

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

clk: samsung: Fix UBSAN panic in samsungclkinit()

With UBSANARRAYBOUNDS=y, I'm hitting the below panic due to dereferencing ctx->clk_data.hws before setting ctx->clk_data.num = nr_clks. Move that up to fix the crash.

UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP <snip> Call trace: samsungclkinit+0x110/0x124 (P) samsungclkinit+0x48/0x124 (L) samsungcmuregisterone+0x3c/0xa0 exynosarm64registercmu+0x54/0x64 __gs101cmutopofclkinitdeclare+0x28/0x60 ...(CVE-2025-39728)

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

fs: Prevent file descriptor table allocations exceeding INT_MAX

When sysctlnropen is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c:

WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmallocnodenoprof+0x21a/0x288

This happens because kvmallocarray() and kvmalloc() check if the requested size exceeds INTMAX and emit a warning when the allocation is not flagged with _GFPNOWARN.

Specifically, when nropen is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INTMAX = 2,147,483,647)

Reproducer: 1. Set /proc/sys/fs/nropen to 1073741816: # echo 1073741816 > /proc/sys/fs/nropen

2. Run a program that uses a high file descriptor:

   include <unistd.h>

   include <sys/resource.h>

   int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }

3. Observe WARNING in dmesg at mm/slub.c:5027

systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that:

1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting
2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations
3. The resulting allocations (>8GB) are impractical and will always fail

systemd's algorithm starts with INTMAX and keeps halving the value until the kernel accepts it. On most systems, this results in nropen being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.

While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue.

Fix this by adding a check in allocfdtable() to ensure the requested allocation size does not exceed INTMAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.(CVE-2025-39756)

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

net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM

When performing Generic Segmentation Offload (GSO) on an IPv6 packet that contains extension headers, the kernel incorrectly requests checksum offload if the egress device only advertises NETIFFIPV6_CSUM feature, which has a strict contract: it supports checksum offload only for plain TCP or UDP over IPv6 and explicitly does not support packets with extension headers. The current GSO logic violates this contract by failing to disable the feature for packets with extension headers, such as those used in GREoIPv6 tunnels.

This violation results in the device being asked to perform an operation it cannot support, leading to a skb_warn_bad_offload warning and a collapse of network throughput. While device TSO/USO is correctly bypassed in favor of software GSO for these packets, the GSO stack must be explicitly told not to request checksum offload.

Mask NETIFFIPV6CSUM, NETIFFTSO6 and NETIFFGSOUDPL4 in gsofeatures_check if the IPv6 header contains extension headers to compute checksum in software.

The exception is a BIG TCP extension, which, as stated in commit 68e068cabd2c6c53 ("net: reenable NETIFFIPV6CSUM offload for BIG TCP packets"): "The feature is only enabled on devices that support BIG TCP TSO. The header is only present for PFPACKET taps like tcpdump, and not transmitted by physical devices."

kernel log output (truncated): WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skbwarnbadoffload+0x81/0x140 ... Call Trace: <TASK> skbchecksumhelp+0x12a/0x1f0 validatexmitskb+0x1a3/0x2d0 validatexmitskblist+0x4f/0x80 schdirectxmit+0x1a2/0x380 __devxmitskb+0x242/0x670 __devqueuexmit+0x3fc/0x7f0 ip6finishoutput2+0x25e/0x5d0 ip6finishoutput+0x1fc/0x3f0 ip6tnlxmit+0x608/0xc00 [ip6tunnel] ip6gretunnelxmit+0x1c0/0x390 [ip6gre] devhardstart_xmit+0x63/0x1c0 __devqueuexmit+0x6d0/0x7f0 ip6finishoutput2+0x214/0x5d0 ip6finishoutput+0x1fc/0x3f0 ip6xmit+0x2ca/0x6f0 ip6finishoutput+0x1fc/0x3f0 ip6xmit+0x2ca/0x6f0 inet6cskxmit+0xeb/0x150 _tcptransmitskb+0x555/0xa80 tcpwritexmit+0x32a/0xe90 tcpsendmsglocked+0x437/0x1110 tcpsendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a(CVE-2025-39770)

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

sctp: initialize more fields in sctpv6from_sk()

syzbot found that sin6scopeid was not properly initialized, leading to undefined behavior.

Clear sin6scopeid and sin6_flowinfo.

BUG: KMSAN: uninit-value in __sctpv6cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctpv6cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctpinet6cmpaddr+0x4f2/0x510 net/sctp/ipv6.c:983 sctpbindaddrconflict+0x22a/0x3b0 net/sctp/bindaddr.c:390 sctpgetportlocal+0x21eb/0x2440 net/sctp/socket.c:8452 sctpgetport net/sctp/socket.c:8523 [inline] sctplistenstart net/sctp/socket.c:8567 [inline] sctpinetlisten+0x710/0xfd0 net/sctp/socket.c:8636 __syslistensocket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __dosyslisten net/socket.c:1932 [inline] __sesyslisten net/socket.c:1930 [inline] _x64syslisten+0x343/0x4c0 net/socket.c:1930 x64syscall+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls64.h:51 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd9/0x210 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable addr.i.i created at: sctpgetport net/sctp/socket.c:8515 [inline] sctplistenstart net/sctp/socket.c:8567 [inline] sctpinetlisten+0x650/0xfd0 net/sctp/socket.c:8636 __syslistensocket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __dosyslisten net/socket.c:1932 [inline] __sesyslisten net/socket.c:1930 [inline] __x64syslisten+0x343/0x4c0 net/socket.c:1930(CVE-2025-39812)

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

scsi: lpfc: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.(CVE-2025-39841)

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

netfilter: brnetfilter: do not check confirmed bit in brnflocalin() after confirm

When send a broadcast packet to a tap device, which was added to a bridge, brnflocal_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen.

------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/brnetfilterhooks.c:632 brnflocalin+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tapsend Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:brnflocalin+0x168/0x200 Call Trace: <TASK> nfhookslow+0x3e/0xf0 brpassframeup+0x103/0x180 brhandleframefinish+0x2de/0x5b0 brnfhookthresh+0xc0/0x120 brnfpreroutingfinish+0x168/0x3a0 brnfprerouting+0x237/0x5e0 brhandle_frame+0x1ec/0x3c0 __netifreceiveskb_core+0x225/0x1210 _netifreceiveskbonecore+0x37/0xa0 netifreceiveskb+0x36/0x160 tungetuser+0xa54/0x10c0 tunchrwriteiter+0x65/0xb0 vfswrite+0x305/0x410 ksyswrite+0x60/0xd0 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]---

To solve the hash conflict, nfctresolveclash() try to merge the conntracks, and update skb->nfct. However, brnflocal_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning.

If confirm() does not insert the conntrack entry and return NFDROP, the warning may also occur. There is no need to reserve the WARNON_ONCE, just remove it.(CVE-2025-39894)

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

net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer

Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkillfindtype() gets called with the possibly uninitialized "const char *type_name;" local variable.

On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpidevice, the rfkill->type is set based on the ACPI acpidevice_id:

    rfkill->type = (unsigned)id->driver_data;

and there is no "type" property so devicepropertyreadstring() will fail and leave typename uninitialized, leading to a potential crash.

rfkillfindtype() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL.

Note likely sofar this has not been caught because:

1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
2. The stack happened to contain NULL where type_name is stored(CVE-2025-39937)

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

tcp: Clear tcpsk(sk)->fastopenrsk in tcp_disconnect().

syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCP_ESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:

1. accept()
2. connect(AF_UNSPEC)
3. connect() to another destination

As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers.

Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.

Let's call reqskfastopenremove() in tcp_disconnect().

Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) __runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) __walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>(CVE-2025-39955)

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

nexthop: Forbid FDB status change while nexthop is in a group

The kernel forbids the creation of non-FDB nexthop groups with FDB nexthops:

# ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops.

And vice versa:

# ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops.

However, as long as no routes are pointing to a non-FDB nexthop group, the kernel allows changing the type of a nexthop from FDB to non-FDB and vice versa:

# ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0

This configuration is invalid and can result in a NPD [1] since FDB nexthops are not associated with a nexthop device:

# ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1

Fix by preventing nexthop FDB status change while the nexthop is in a group:

# ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group.

[1] BUG: kernel NULL pointer dereference, address: 00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:fiblookupgoodnhc+0x1e/0x80 [...] Call Trace: <TASK> fibtablelookup+0x541/0x650 iprouteoutputkeyhashrcu+0x2ea/0x970 iprouteoutputkeyhash+0x55/0x80 __ip4datagramconnect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64sysconnect+0x18/0x20 dosyscall64+0xa4/0x2a0 entrySYSCALL64afterhwframe+0x4b/0x53(CVE-2025-39980)

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

ipvs: Defer ipvsftp unregister during netns cleanup

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

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

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

crypto: hisilicon/qm - set NULL to qm->debug.qmdiffregs

When the initialization of qm->debug.accdiffreg fails, the probe process does not exit. However, after qm->debug.qmdiffregs is freed, it is not set to NULL. This can lead to a double free when the remove process attempts to free it again. Therefore, qm->debug.qmdiffregs should be set to NULL after it is freed.(CVE-2025-40062)

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

bpf: Explicitly check accesses to bpfsockaddr

Syzkaller found a kernel warning on the following sock_addr program:

0: r0 = 0
1: r2 = *(u32 *)(r1 +60)
2: exit

which triggers:

verifier bug: error during ctx access conversion (0)

This is happening because offset 60 in bpfsockaddr corresponds to an implicit padding of 4 bytes, right after msgsrcip4. Access to this padding isn't rejected in sockaddrisvalidaccess and it thus later fails to convert the access.

This patch fixes it by explicitly checking the various fields of bpfsockaddr in sockaddrisvalidaccess.

I checked the other ctx structures and isvalidaccess functions and didn't find any other similar cases. Other cases of (properly handled) padding are covered in new tests in a subsequent patch.(CVE-2025-40078)

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

crypto: hisilicon/qm - request reserved interrupt for virtual function

The device interrupt vector 3 is an error interrupt for physical function and a reserved interrupt for virtual function. However, the driver has not registered the reserved interrupt for virtual function. When allocating interrupts, the number of interrupts is allocated based on powers of two, which includes this interrupt. When the system enables GICv4 and the virtual function passthrough to the virtual machine, releasing the interrupt in the driver triggers a warning.

The WARNING report is: WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 itsfreeite+0x94/0xb4

Therefore, register a reserved interrupt for VF and set the IRQFNOAUTOEN flag to avoid that warning.(CVE-2025-40136)

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

sctp: avoid NULL dereference when chunk data buffer is missing

chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only.

chunk->skb can only be NULL if chunk->headskb is not. Check for fraglist instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.(CVE-2025-40240)

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

net: openvswitch: remove never-working support for setting nsh fields

The validation of the set(nsh(...)) action is completely wrong. It runs through the nshkeyputfromnlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible.

There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'ismask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SWFLOWKEYPUT() during validation, while validate_nsh() doesn't allocate any memory for it:

BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nshkeyputfromnlattr+0x19d/0x610 [openvswitch] Call Trace: <TASK> validatensh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovsnlacopyactions+0x477/0x860 [openvswitch] ovsnlacopyactions+0x8d/0x100 [openvswitch] ovspacketcmdexecute+0x1cc/0x310 [openvswitch] genlfamilyrcvmsgdoit+0xdb/0x130 genlfamilyrcvmsg+0x14b/0x220 genlrcvmsg+0x47/0xa0 netlinkrcvskb+0x53/0x100 genlrcv+0x24/0x40 netlinkunicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 _syssendmsg+0x6d/0xd0 dosyscall64+0x7b/0x2c0 entrySYSCALL64afterhwframe+0x76/0x7e

The third issue with this process is that while trying to convert the non-masked set into masked one, validateset() copies and doubles the size of the OVSKEYATTRNSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump.

In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up.

Fixing all the issues is a complex task as it requires re-writing most of the validation code.

Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.(CVE-2025-40254)

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

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

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

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

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

Let's hold RTNL in tipcnetfinalize_work().

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

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

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

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

sctp: prevent possible shift-out-of-bounds in sctptransportupdate_rto

syzbot reported a possible shift-out-of-bounds [1]

Blamed commit added rtoalphamax and rtobetamax set to 1000.

It is unclear if some sctp users are setting very large rtoalpha and/or rtobeta.

In order to prevent user regression, perform the test at run time.

Also add READ_ONCE() annotations as sysctl values can change under us.

[1]

UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: <TASK> __dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x16c/0x1f0 lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:233 [inline] _ubsanhandleshiftoutofbounds+0x27f/0x420 lib/ubsan.c:494 sctptransportupdaterto.cold+0x1c/0x34b net/sctp/transport.c:509 sctpchecktransmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctpoutqsack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctpcmdprocesssack net/sctp/smsideeffect.c:840 [inline] sctpcmdinterpreter net/sctp/smsideeffect.c:1372 inline

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

sctp: Prevent TOCTOU out-of-bounds write

For the following path not holding the sock lock,

sctpdiagdump() -> sctpforeachendpoint() -> sctpep_dump()

make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use).(CVE-2025-40331)

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

libceph: replace BUGON with bounds check for map->maxosd

OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd.

idryomov: drop BUGON in cephgetprimaryaffinity(), minor cosmetic edits

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

libceph: prevent potential out-of-bounds writes in handleauthsession_key()

The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets.

idryomov: changelog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bluetooth: hcicore: lookup hciconn on RX path on protocol side

The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hciconn* is not concurrently modified/deleted. This locking appears to be leftover from before connhash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then.

Currently, there are code paths that delete hciconn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hcisync: Fix UAF on hciabortconn_sync") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible.

Move the lookup of hciconn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hciconn* usage and lookup.

syzkaller has reported a crash that appears to be this issue:

[Task hdev->workqueue]          [Task 2]
                                hci_disconnect_all_sync
l2cap_recv_acldata(hcon)
                                  hci_conn_get(hcon)
                                  hci_abort_conn_sync(hcon)
                                    hci_dev_lock
  hci_dev_lock
                                    hci_conn_del(hcon)
  v-------------------------------- hci_dev_unlock
                                  hci_conn_put(hcon)
  conn = hcon->l2cap_data (UAF)(CVE-2025-68304)

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

ima: Handle error code returned by imafilterrule_match()

In imamatchrules(), if imafilterrule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA.

This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before imalsmrules is updated, in imamatchrules(), the first call to imafilterrulematch() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rulereinitialized)' block, perform imalsmcopyrule() and retry. In imalsmcopyrule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to imafilterrule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match.

Call trace: selinuxauditrulematch+0x310/0x3b8 securityauditrulematch+0x60/0xa0 imamatchrules+0x2e4/0x4a0 imamatchpolicy+0x9c/0x1e8 imagetaction+0x48/0x60 processmeasurement+0xf8/0xa98 imabprmcheck+0x98/0xd8 securitybprmcheck+0x5c/0x78 searchbinaryhandler+0x6c/0x318 execbinprm+0x58/0x1b8 bprmexecve+0xb8/0x130 doexecveat_common.isra.0+0x1a8/0x258 _arm64sysexecve+0x48/0x68 invokesyscall+0x50/0x128 el0svccommon.constprop.0+0xc8/0xf0 doel0svc+0x24/0x38 el0svc+0x44/0x200 el0t64synchandler+0x100/0x130 el0t64sync+0x3c8/0x3d0

Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.(CVE-2025-68740)

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

bpf: Fix invalid prog->stats access when updateeffectiveprogs fails

Syzkaller triggers an invalid memory access issue following fault injection in updateeffectiveprogs. The issue can be described as follows:

_cgroupbpfdetach updateeffectiveprogs computeeffectiveprogs bpfprogarrayalloc <-- fault inject purgeeffectiveprogs /* change to dummybpfprog */ array->items[index] = &dummybpfprog.prog

---softirq start--- __do_softirq ... __cgroupbpfrunfilterskb __bpfprogrunsavecb bpfprogrun stats = thiscpuptr(prog->stats) /* invalid memory access */ flags = u64statsupdatebeginirqsave(&stats->syncp) ---softirq end---

staticbranchdec(&cgroupbpfenabled_key[atype])

The reason is that fault injection caused updateeffectiveprogs to fail and then changed the original prog into dummybpfprog.prog in purgeeffectiveprogs. Then a softirq came, and accessing the members of dummybpfprog.prog in the softirq triggers invalid mem access.

To fix it, skip updating stats when stats is NULL.(CVE-2025-68742)

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

ethtool: Avoid overflowing userspace buffer on stats query

The ethtool -S command operates across three ioctl calls: ETHTOOLGSSETINFO for the size, ETHTOOLGSTRINGS for the names, and ETHTOOLGSTATS for the values.

If the number of stats changes between these calls (e.g., due to device reconfiguration), userspace's buffer allocation will be incorrect, potentially leading to buffer overflow.

Drivers are generally expected to maintain stable stat counts, but some drivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making this scenario possible.

Some drivers try to handle this internally: - bnadgetethtoolstats() returns early in case stats.nstats is not equal to the driver's stats count. - micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.

However, both use stats.nstats which is already assigned with the value returned from getsset_count(), hence won't solve the issue described here.

Change ethtoolgetstrings(), ethtoolgetstats(), ethtoolgetphystats() to not return anything in case of a mismatch between userspace's size and getssetsize(), to prevent buffer overflow. The returned nstats value will be equal to zero, to reflect that nothing has been returned.

This could result in one of two cases when using upstream ethtool, depending on when the size change is detected: 1. When detected in ethtoolgetstrings(): # ethtool -S eth2 no stats available

2. When detected in get stats, all stats will be reported as zero.

Both cases are presumably transient, and a subsequent ethtool call should succeed.

Other than the overflow avoidance, these two cases are very evident (no output/cleared stats), which is arguably better than presenting incorrect/shifted stats. I also considered returning an error instead of a "silent" response, but that seems more destructive towards userspace apps.

Notes: - This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.

• RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.

• Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.(CVE-2025-68795)

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

ext4: xattr: fix null pointer deref in ext4rawinode()

If ext4getinodeloc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4xattrinodedecrefall() lacks error checking, this will lead to a null pointer dereference in ext4rawinode(), called right after ext4getinode_loc().

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

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

net: hns3: using the num_tqps in the vf driver to apply for resources

Currently, hdev->htqp is allocated using hdev->numtqps, and kinfo->tqp is allocated using kinfo->numtqps. However, kinfo->numtqps is set to min(newtqps, hdev->numtqps); Therefore, kinfo->numtqps may be smaller than hdev->numtqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevfknic_setup().

Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized.(CVE-2025-71064)

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

net/sched: schqfq: Fix NULL deref when deactivating inactive aggregate in qfqreset

qfq_class->leaf_qdisc->q.qlen > 0 does not imply that the class itself is active.

Two qfqclass objects may point to the same leafqdisc. This happens when:

1. one QFQ qdisc is attached to the dev as the root qdisc, and

2. another QFQ qdisc is temporarily referenced (e.g., via qdiscget() / qdiscput()) and is pending to be destroyed, as in function tcnewtfilter.

When packets are enqueued through the root QFQ qdisc, the shared leafqdisc->q.qlen increases. At the same time, the second QFQ qdisc triggers qdiscput and qdiscdestroy: the qdisc enters qfqreset() with its own q->q.qlen == 0, but its class's leaf qdisc->q.qlen > 0. Therefore, the qfqreset would wrongly deactivate an inactive aggregate and trigger a null-deref in qfqdeactivate_agg:

[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 0.903571] #PF: supervisor write access in kernel mode [ 0.903860] #PF: errorcode(0x0002) - not-present page [ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0 [ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI [ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE [ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 0.905754] RIP: 0010:qfqdeactivateagg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/schqfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2)) [ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0

Code starting with the faulting instruction

0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ... [ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246 [ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000 [ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000 [ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000 [ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880 [ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000 [ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0 [ 0.910247] PKRU: 55555554 [ 0.910391] Call Trace: [ 0.910527] <TASK> [ 0.910638] qfqresetqdisc (net/sched/schqfq.c:357 net/sched/schqfq.c:1485) [ 0.910826] qdiscreset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/schgeneric.c:1036) [ 0.911040] __qdiscdestroy (net/sched/schgeneric.c:1076) [ 0.911236] tc_newtfilter (net/sched/clsapi.c:2447) [ 0.911447] rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) [ 0.911663] ? __pfxrtnetlinkrcv_msg (net/core/rtnetlink.c:6861) [ 0.911894] netlinkrcvskb (net/netlink/afnetlink.c:2550) [ 0.912100] netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) [ 0.912296] ? __allocskb (net/core/skbuff.c:706) [ 0.912484] netlinksendmsg (net/netlink/af ---truncated---(CVE-2026-22976)

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

bpf: Fix reference count leak in bpfprogtestrunxdp()

syzbot is reporting

unregister_netdevice: waiting for sit0 to become free. Usage count = 2

problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().

According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().

Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().(CVE-2026-22994)

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

NFS: Fix a deadlock involving nfsreleasefolio()

Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery waiting on kthreadd, which is attempting to reclaim memory by calling nfsreleasefolio(). The latter cannot make progress due to state recovery being needed.

It seems that the only safe thing to do here is to kick off a writeback of the folio, without waiting for completion, or else kicking off an asynchronous commit.(CVE-2026-23053)

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

media: dvb-core: fix wrong reinitialization of ringbuffer on reopen

dvbdvropen() calls dvbringbufferinit() when a new reader opens the DVR device. dvbringbufferinit() calls initwaitqueuehead(), which reinitializes the waitqueue list head to empty.

Since dmxdev->dvrbuffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from iouring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}.

The waitqueue and spinlock in dvrbuffer are already properly initialized once in dvbdmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions.

Replace the dvbringbufferinit() call in dvbdvropen() with direct assignment of data/size and a call to dvbringbufferreset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.(CVE-2026-23253)

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

regmap: maple: free entry on masstoregfp() failure

regcachemaplewrite() allocates a new block ('entry') to merge adjacent ranges and then stores it with masstoregfp(). When masstoregfp() fails, the new 'entry' remains allocated and is never freed, leaking memory.

Free 'entry' on the failure path; on success continue freeing the replaced neighbor blocks ('lower', 'upper').(CVE-2026-23260)

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

apparmor: fix unprivileged local user can do privileged policy management

An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface.

This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation.

The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces.

Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check.(CVE-2026-23268)

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

perf: Fix _perfeventoverflow() vs perfremovefromcontext() race

Make sure that __perfeventoverflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled.

This opens up a race vs perfeventexit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program.(CVE-2026-23271)

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

macvlan: observe an RCU grace period in macvlancommonnewlink() error path

valis reported that a race condition still happens after my prior patch.

macvlancommonnewlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).

We must respect an RCU period, either in macvlan or the core networking stack.

After adding a temporary mdelay(1000) in macvlanforwardsource_one() to open the race window, valis repro was:

ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source

(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument

BUG: KASAN: slab-use-after-free in macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175

CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:123) printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasanreport (mm/kasan/report.c:597) ? macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? taskletinit (kernel/softirq.c:983) macvlanhandleframe (drivers/net/macvlan.c:501)

Allocated by task 169: kasansavestack (mm/kasan/common.c:58) kasansavetrack (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmallocnodenoprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) allocnetdevmqs (net/core/dev.c:12012) rtnl_createlink (net/core/rtnetlink.c:3648) rtnlnewlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) _x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:131)

Freed by task 169: kasansavestack (mm/kasan/common.c:58) kasansavetrack (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasansavefree_info (mm/kasan/generic.c:587) __kasanslabfree (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnlnewlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) _x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:131)(CVE-2026-23273)

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

scsi: target: Fix recursive locking in __configfsopenfile()

In flushwritebuffer, &p->fragsem is acquired and then the loaded store function is called, which, here, is targetcoreitemdbrootstore(). This function called filpopen(), following which these functions were called (in reverse order), according to the call trace:

down_read __configfsopenfile dodentryopen vfsopen doopen pathopenat dofilpopen fileopenname filpopen targetcoreitemdbrootstore flushwritebuffer configfswriteiter

targetcoreitemdbrootstore() tries to validate the new file path by trying to open the file path provided to it; however, in this case, the bug report shows:

db_root: not a directory: /sys/kernel/config/target/dbroot

indicating that the same configfs file was tried to be opened, on which it is currently working on. Thus, it is trying to acquire fragsem semaphore of the same file of which it already holds the semaphore obtained in flushwrite_buffer(), leading to acquiring the semaphore in a nested manner and a possibility of recursive locking.

Fix this by modifying targetcoreitemdbrootstore() to use kernpath() instead of filpopen() to avoid opening the file using filesystem-specific function __configfsopenfile(), and further modifying it to make this fix compatible.(CVE-2026-23292)

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

scsi: core: Fix refcount leak for tagset_refcnt

This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace:

[130120.652718] scsiallocsdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured

PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: "iscsid" #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __waitforcommon at ffffffff8606674f #4 [ffffb5b9c134bb10] scsiremovehost at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsiswtcpsessiondestroy at ffffffffc03031c4 [iscsitcp] #6 [ffffb5b9c134bb48] iscsiifrecvmsg at ffffffffc0292692 [scsitransportiscsi] #7 [ffffb5b9c134bb98] iscsiifrx at ffffffffc02929c2 [scsitransportiscsi] #8 [ffffb5b9c134bbf0] netlinkunicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlinksendmsg at ffffffff85e554ef(CVE-2026-23296)

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

i40e: Fix preempt count leak in napi poll tracepoint

Using getcpu() in the tracepoint assignment causes an obvious preempt count leak because nothing invokes putcpu() to undo it:

softirq: huh, entered softirq 3 NETRX with preemptcount 00000100, exited with 00000101?

This clearly has seen a lot of testing in the last 3+ years...

Use smpprocessorid() instead.(CVE-2026-23313)

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

drm/vmwgfx: Return the correct value in vmwtranslateptr functions

Before the referenced fixes these functions used a lookup function that returned a pointer. This was changed to another lookup function that returned an error code with the pointer becoming an out parameter.

The error path when the lookup failed was not changed to reflect this change and the code continued to return the PTRERR of the now uninitialized pointer. This could cause the vmwtranslate_ptr functions to return success when they actually failed causing further uninitialized and OOB accesses.(CVE-2026-23317)

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

bpf: Fix a UAF issue in bpftrampolinelinkcgroupshim

The root cause of this bug is that when 'bpflinkput' reduces the refcount of 'shimlink->link.link' to zero, the resource is considered released but may still be referenced via 'tr->progshlist' in 'cgroupshimfind'. The actual cleanup of 'tr->progshlist' in 'bpfshimtramplinkrelease' is deferred. During this window, another process can cause a use-after-free via 'bpftrampolinelinkcgroup_shim'.

Based on Martin KaFai Lau's suggestions, I have created a simple patch.

To fix this: Add an atomic non-zero check in 'bpftrampolinelinkcgroupshim'. Only increment the refcount if it is not already zero.

Testing: I verified the fix by adding a delay in 'bpfshimtramplinkrelease' to make the bug easier to trigger:

static void bpfshimtramplinkrelease(struct bpflink link) { / ... */ if (!shimlink->trampoline) return;

• msleep(100); WARNONONCE(bpftrampolineunlinkprog(&shimlink->link, shimlink->trampoline, NULL)); bpftrampolineput(shimlink->trampoline); }

Before the patch, running a PoC easily reproduced the crash(almost 100%) with a call trace similar to KaiyanM's report. After the patch, the bug no longer occurs even after millions of iterations.(CVE-2026-23319)

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

x86/efi: defer freeing of boot services memory

efifreebootservices() frees memory occupied by EFIBOOTSERVICESCODE and EFIBOOTSERVICESDATA using memblockfree_late().

There are two issue with that: memblockfreelate() should be used for memory allocated with memblockalloc() while the memory reserved with memblockreserve() should be freed with freereservedarea().

More acutely, with CONFIGDEFERREDSTRUCTPAGEINIT=y efifreeboot_services() is called before deferred initialization of the memory map is complete.

Benjamin Herrenschmidt reports that this causes a leak of ~140MB of RAM on EC2 t3a.nano instances which only have 512MB or RAM.

If the freed memory resides in the areas that memory map for them is still uninitialized, they won't be actually freed because memblockfreelate() calls memblockfreepages() and the latter skips uninitialized pages.

Using freereservedarea() at this point is also problematic because _freepage() accesses the buddy of the freed page and that again might end up in uninitialized part of the memory map.

Delaying the entire efifreeboot_services() could be problematic because in addition to freeing boot services memory it updates efi.memmap without any synchronization and that's undesirable late in boot when there is concurrency.

More robust approach is to only defer freeing of the EFI boot services memory.

Split efifreebootservices() in two. First efiunmapbootservices() collects ranges that should be freed into an array then efifreeboot_services() later frees them after deferred init is complete.(CVE-2026-23352)

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

bpf: Fix stack-out-of-bounds write in devmap

getupperifindexes() iterates over all upper devices and writes their indices into an array without checking bounds.

Also the callers assume that the max number of upper devices is MAXNESTDEV and allocate excludeddevices[1+MAXNESTDEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAXNEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write.

Add a max parameter to getupperifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect.

To reproduce, create more than MAXNESTDEV(8) macvlans on a device with an XDP program attached using BPFFBROADCAST | BPFFEXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.(CVE-2026-23359)

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

nvme: fix admin queue leak on controller reset

When nvmeallocadmintagset() is called during a controller reset, a previous admin queue may still exist. Release it properly before allocating a new one to avoid orphaning the old queue.

This fixes a regression introduced by commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime").(CVE-2026-23360)

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

blktrace: fix __thiscpuread/write in preemptible context

tracingrecordcmdline() internally uses __thiscpuread() and _thiscpuwrite() on the per-CPU variable tracecmdlinesave, and tracesavecmdline() explicitly asserts preemption is disabled via lockdepassertpreemptiondisabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probewakeupschedswitch() / probewakeup()).

_blkaddtrace() was calling tracingrecordcmdline(current) early in the blktracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002:

blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)

[ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 [ 81.362895] checkpreemptiondisabled+0xce/0xe0 [ 81.362902] tracingrecordcmdline+0x10/0x40 [ 81.362923] __blkaddtrace+0x307/0x5d0 [ 81.362934] ? lock_acquire+0xe0/0x300 [ 81.362940] ? ioviterextractpages+0x101/0xa30 [ 81.362959] blkaddtracebio+0x106/0x1e0 [ 81.362968] submitbionoacctnocheck+0x24b/0x3a0 [ 81.362979] ? lockdepinitmaptype+0x58/0x260 [ 81.362988] submitbiowait+0x56/0x90 [ 81.363009] __blkdevdirectIO_simple+0x16c/0x250 [ 81.363026] ? _pfxsubmitbiowaitendio+0x10/0x10 [ 81.363038] ? rcureadlockanyheld+0x73/0xa0 [ 81.363051] blkdevreaditer+0xc1/0x140 [ 81.363059] vfsread+0x20b/0x330 [ 81.363083] ksysread+0x67/0xe0 [ 81.363090] dosyscall64+0xbf/0xf00 [ 81.363102] entrySYSCALL64afterhwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] </TASK>

The same BUG fires from blkaddtraceplug(), blkaddtraceunplug(), and blkaddtrace_rq() paths as well.

The purpose of tracin ---truncated---(CVE-2026-23374)

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

bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing

struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.

Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary.

This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITEONCE() in bpfarchtextpoke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.

Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpfjitbinarypackalloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field.(CVE-2026-23383)

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

Squashfs: check metadata block offset is within range

Syzkaller reports a "general protection fault in squashfscopydata"

This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset.

This is subsequently passed to squashfscopydata (via squashfsreadmetadata) where the negative offset causes an out of bounds access.

The fix is to check that the offset is within range in squashfsreadmetadata. This will trap this and other cases.(CVE-2026-23388)

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

ext4: reject mount if bigalloc with sfirstdata_block != 0

bigalloc with sfirstdata_block != 0 is not supported, reject mounting it.(CVE-2026-31447)

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

HID: multitouch: Check to ensure report responses match the request

It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)

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

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hidreportraw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires <(CVE-2026-43048)

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

xfs: close crash window in attr dabtree inactivation

When inactivating an inode with node-format extended attributes, xfsattr3nodeinactive() invalidates all child leaf/node blocks via xfstransbinval(), but intentionally does not remove the corresponding entries from their parent node blocks. The implicit assumption is that xfsattr_inactive() will truncate the entire attr fork to zero extents afterwards, so log recovery will never reach the root node and follow those stale pointers.

However, if a log shutdown occurs after the leaf/node block cancellations commit but before the attr bmap truncation commits, this assumption breaks. Recovery replays the attr bmap intact (the inode still has attr fork extents), but suppresses replay of all cancelled leaf/node blocks, maybe leaving them as stale data on disk. On the next mount, xlogrecoverprocess_iunlinks() retries inactivation and attempts to read the root node via the attr bmap. If the root node was not replayed, reading the unreplayed root block triggers a metadata verification failure immediately; if it was replayed, following its child pointers to unreplayed child blocks triggers the same failure:

XFS (pmem0): Metadata corruption detected at xfsda3nodereadverify+0x53/0x220, xfsda3node block 0x78 XFS (pmem0): Unmount and run xfsrepair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfsdareadbuf+0x104/0x190" at daddr 0x78 len 8 error 117

Fix this in two places:

In xfsattr3nodeinactive(), after calling xfstransbinval() on a child block, immediately remove the entry that references it from the parent node in the same transaction. This eliminates the window where the parent holds a pointer to a cancelled block. Once all children are removed, the now-empty root node is converted to a leaf block within the same transaction. This node-to-leaf conversion is necessary for crash safety. If the system shutdown after the empty node is written to the log but before the second-phase bmap truncation commits, log recovery will attempt to verify the root block on disk. xfsda3nodeverify() does not permit a node block with count == 0; such a block will fail verification and trigger a metadata corruption shutdown. on the other hand, leaf blocks are allowed to have this transient state.

In xfsattrinactive(), split the attr fork truncation into two explicit phases. First, truncate all extents beyond the root block (the child extents whose parent references have already been removed above). Second, invalidate the root block and truncate the attr bmap to zero in a single transaction. The two operations in the second phase must be atomic: as long as the attr bmap has any non-zero length, recovery can follow it to the root block, so the root block invalidation must commit together with the bmap-to-zero truncation.(CVE-2026-43053)

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

Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"

This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"), which causes a deadlock by recursively taking pcirescanremovelock when sriovdelvfs() is called as part of pcistopandremovebusdevice(). For example with the following sequence of commands:

$ echo <NUM> > /sys/bus/pci/devices/<pf>/sriov_numvfs $ echo 1 > /sys/bus/pci/devices/<pf>/remove

A trimmed trace of the deadlock on a mlx5 device is as below:

zsh/5715 is trying to acquire lock: 000002597926ef50 (pcirescanremovelock){+.+.}-{3:3}, at: sriovdisable+0x34/0x140

but task is already holding lock: 000002597926ef50 (pcirescanremovelock){+.+.}-{3:3}, at: pcistopandremovebusdevicelocked+0x24/0x80 ... Call Trace: [<00000259778c4f90>] dumpstacklvl+0xc0/0x110 [<00000259779c844e>] printdeadlock_bug+0x31e/0x330 [<00000259779c1908>] __lockacquire+0x16c8/0x32f0 [<00000259779bffac>] lockacquire+0x14c/0x350 [<00000259789643a6>] __mutexlockcommon+0xe6/0x1520 [<000002597896413c>] mutexlocknested+0x3c/0x50 [<00000259784a07e4>] sriovdisable+0x34/0x140 [<00000258f7d6dd80>] mlx5sriovdisable+0x50/0x80 [mlx5core] [<00000258f7d5745e>] removeone+0x5e/0xf0 [mlx5core] [<00000259784857fc>] pcideviceremove+0x3c/0xa0 [<000002597851012e>] devicereleasedriverinternal+0x18e/0x280 [<000002597847ae22>] pcistopbusdevice+0x82/0xa0 [<000002597847afce>] pcistopandremovebusdevicelocked+0x5e/0x80 [<00000259784972c2>] removestore+0x72/0x90 [<0000025977e6661a>] kernfsfopwriteiter+0x15a/0x200 [<0000025977d7241c>] vfswrite+0x24c/0x300 [<0000025977d72696>] ksyswrite+0x86/0x110 [<000002597895b61c>] __dosyscall+0x14c/0x400 [<000002597896e0ee>] systemcall+0x6e/0x90

This alone is not a complete fix as it restores the issue the cited commit tried to solve. A new fix will be provided as a follow on.(CVE-2026-43147)

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

arm64: Add support for TSV110 Spectre-BHB mitigation

The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.(CVE-2026-43261)

In the Linux kernel, the kexecloadpurgatory() function derives image->start by locating eentry inside an SHFEXECINSTR section. If the purgatory object contains multiple executable sections with overlapping shaddr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatorystart symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol.(CVE-2026-43289)

In the Linux kernel, there is a potential out-of-bounds access vulnerability in the cephhandleauthreply() function of the libceph component. When processing messages of type CEPHMSGAUTHREPLY, the value of the payloadlen field is stored in a variable of type int. A value greater than INTMAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because cephdecodeneed() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)

In the Linux kernel, when an alias is found through dsplicealias in the nfs3proccreate function, if the alias happens to be a directory dentry, the system does not return any error but simply forgets about this alias, leaving the original dentry to be added as negative. This later causes a system crash in nfsatomicopenv23/finishopen since a negative dentry is supplied to dodentryopen. This issue was observed running lustre-racer, where directories and files are created/removed concurrently with the same name and O_EXCL is not used to open files.(CVE-2026-43470)