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

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NFHOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NFSTOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

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

netfilter: nftsetpipapoavx2: don't return non-matching entry on expiry

New test case fails unexpectedly when avx2 matching functions are used.

The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo.

This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f -

This is expected to work, because its the same set after all and it was already loaded once.

But with avx2, this fails: nft reports a clashing element.

The reported clash is of following form:

We successfully re-inserted a . b c . d

Then we try to insert a . d

avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next.

Due to incorrect masking, the skip-step finds the next matching element only considering the first field,

i.e. we return the already reinserted "a . b", even though the last field is different and the entry should not have been matched.

No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nftpipapoavx2lookupslow' fallback.

Bisection points to 7711f4bb4b36 ("netfilter: nftsetpipapo: fix range overlap detection") but that fix merely uncovers this bug.

Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate.

The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.

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

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

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

wifi: rt2x00usb: fix devres lifetime

USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes).

Fix the USB anchor lifetime so that it is released on driver unbind.

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

NFC: nxp-nci: allow GPIOs to sleep

Allow the firmware and enable GPIOs to sleep.

This fixes a WARNON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders.

-- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiodsetvalue+0x88/0x98 -- >8 --

drm/i915/gt: Check setdefaultsubmission() before deferencing

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

RDMA/efa: Fix use of completion ctx after free

On admin queue completion handling, if the admin command completed with error we print data from the completion context. The issue is that we already freed the completion context in polling/interrupts handler which means we print data from context in an unknown state (it might be already used again). Change the admin submission flow so alloc/dealloc of the context will be symmetric and dealloc will be called after any potential use of the context.

HID: asus: avoid memory leak in asusreportfixup()

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

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.

HID: magicmouse: avoid memory leak in magicmousereportfixup()

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

module: Fix kernel panic when a symbol stshndx is out of bounds

The module loader doesn't check for bounds of the ELF section index in simplifysymbols():

for (i = 1; i < symsec->shsize / sizeof(ElfSym); i++) { const char name = info->strtab + sym[i].stname;

switch (sym[i].stshndx) { case SHNCOMMON:

[...]

default: / Divert to percpu allocation if a percpu var. / if (sym[i].stshndx == info->index.pcpu) secbase = (unsigned long)modpercpu(mod); else / HERE --> / secbase = info->sechdrs[sym[i].stshndx].shaddr; sym[i].stvalue += secbase; break; } }

A symbol with an out-of-bounds stshndx value, for example 0xffff (known as SHNXINDEX or SHNHIRESERVE), may cause a kernel panic:

BUG: unable to handle page fault for address: ... RIP: 0010:simplifysymbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception

This can happen when module ELF is legitimately using SHNXINDEX or when it is corrupted.

Add a bounds check in simplifysymbols() to validate that stshndx is within the valid range before using it.

This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1].

[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/

btrfs: set BTRFSROOTORPHANCLEANUP during subvol create

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

xfrm: prevent policyhthresh.work from racing with netns teardown

A XFRMMSGNEWSPDINFO request can queue the per-net work item policyhthresh.work onto the system workqueue.

The queued callback, xfrmhashrebuild(), retrieves the enclosing struct net via containerof(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrmhashrebuild() may then dereference stale memory.

xfrmpolicyfini() already flushes policyhashwork during teardown, but it does not synchronize policyhthresh.work.

Synchronize policyhthresh.work in xfrmpolicyfini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.

esp: fix skb leak with espintcp and async crypto

afkey: validate families in pfkeysendmigrate()

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

spi: use generic driveroverride infrastructure

When a driver is probed through driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driveroverride infrastructure taking care of proper locking internally.

Note that calling match() from driverattach() without the device lock held is intentional. [1]

Also note that we do not enable the driveroverride feature of struct bustype, as SPI - in contrast to most other buses - passes "" to sysfsemit() when the driveroverride pointer is NULL. Thus, printing "\n" instead of "(null)\n".

Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2capecreddatarcv()

Bluetooth: L2CAP: Fix null-ptr-deref on l2capsockreadycb

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

net: openvswitch: Avoid releasing netdev before teardown completes

The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdevdestroy() callback can proceed immediately to the callrcu() invocation if the IFFOVSDATAPATH flag is already cleared on the netdev.

The ovsnetdevdetachdev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdevdestroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like:

[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el102.x8664+rt #1 PREEMPTRT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:devsetpromiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] <TASK> [ 998.393952] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393961] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393975] ? dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394009] ? diebody.cold+0x8/0x12 [ 998.394016] ? dieaddr+0x3c/0x60 [ 998.394027] ? excgeneralprotection+0x16d/0x390 [ 998.394042] ? asmexcgeneralprotection+0x26/0x30 [ 998.394058] ? devsetpromiscuity+0x8d/0xa0 [ 998.394066] ? ovsnetdevdetachdev+0x3a/0x80 [openvswitch] [ 998.394092] dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394102] notifiercallchain+0x5a/0xd0 [ 998.394106] unregisternetdevicemanynotify+0x51b/0xa60 [ 998.394110] rtnldellink+0x169/0x3e0 [ 998.394121] ? rtmutexslowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlinkrcvmsg+0x142/0x3f0 [ 998.394128] ? avchaspermnoaudit+0x69/0xf0 [ 998.394130] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 998.394132] netlinkrcvskb+0x50/0x100 [ 998.394138] netlinkunicast+0x292/0x3f0 [ 998.394141] netlinksendmsg+0x21b/0x470 [ 998.394145] syssendmsg+0x39d/0x3d0 [ 998.394149] syssendmsg+0x9a/0xe0 [ 998.394156] syssendmsg+0x7a/0xd0 [ 998.394160] dosyscall64+0x7f/0x170 [ 998.394162] entrySYSCALL64afterhwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---

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

spi: meson-spicc: Fix double-put in remove path

mesonspiccprobe() registers the controller with devmspiregistercontroller(), so teardown already drops the controller reference via devm cleanup.

Calling spicontrollerput() again in mesonspiccremove() causes a double-put.

hwmon: (pmbus/core) Protect regulator operations with mutex

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

net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query

Fix a "scheduling while atomic" bug in mlx5eipsecinitmacs() by replacing mlx5querymacaddress() with etheraddrcopy() to get the local MAC address directly from netdev->devaddr.

The issue occurs because mlx5querymacaddress() queries the hardware which involves mlx5cmdexec() that can sleep, but it is called from the mlx5eipsechandleevent workqueue which runs in atomic context.

The MAC address is already available in netdev->devaddr, so no need to query hardware. This avoids the sleeping call and resolves the bug.

Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 schedule+0x7ab/0xa20 schedule+0x1c/0xb0 scheduletimeout+0x6e/0xf0 waitforcommon+0x91/0x1b0 cmdexec+0xa85/0xff0 [mlx5core] mlx5cmdexec+0x1f/0x50 [mlx5core] mlx5querynicvportmacaddress+0x7b/0xd0 [mlx5core] mlx5querymacaddress+0x19/0x30 [mlx5core] mlx5eipsecinitmacs+0xc1/0x720 [mlx5core] mlx5eipsecbuildaccelxfrmattrs+0x422/0x670 [mlx5core] mlx5eipsechandleevent+0x2b9/0x460 [mlx5core] processonework+0x178/0x2e0 workerthread+0x2ea/0x430

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

rxrpc: proc: size address buffers for %pISpc output

The AFRXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".

That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6addrisisatap().

As a result, a case such as

[ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535

is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.

Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().

Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example

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

s390/mm: Add missing secure storage access fixups for donated memory

There are special cases where secure storage access exceptions happen in a kernel context for pages that don't have the PGarch1 bit set. That bit is set for non-exported guest secure storage (memory) but is absent on storage donated to the Ultravisor since the kernel isn't allowed to export donated pages.

Prior to this patch we would try to export the page by calling archmakefolioaccessible() which would instantly return since the arch bit is absent signifying that the page was already exported and no further action is necessary. This leads to secure storage access exception loops which can never be resolved.

With this patch we unconditionally try to export and if that fails we fixup.

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

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

nvmet: move async event work off nvmet-wq

For target nvmetctrlfree() flushes ctrl->asynceventwork. If nvmetctrlfree() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-

A. Async event work queued on nvmet-wq (prior to disconnect): nvmetexecuteasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

nvmetaddasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

B. Full pre-work chain (RDMA CM path): nvmetrdmacmhandler() nvmetrdmaqueuedisconnect() nvmetrdmaqueuedisconnect() queuework(nvmetwq, &queue->releasework) processonework() lock((wqcompletion)nvmet-wq) <--------- 1st nvmetrdmareleasequeuework()

C. Recursive path (same worker): nvmetrdmareleasequeuework() nvmetrdmafreequeue() nvmetsqdestroy() nvmetctrlput() nvmetctrlfree() flushwork(&ctrl->asynceventwork) flushwork() touchwqlockdepmap() lock((wqcompletion)nvmet-wq) <--------- 2nd

Lockdep splat:

============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90

but task is already holding lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660

3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660 #1: ffffc9000e6cbe28 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x660 #2: ffffffff82d4db60 (rcureadlock){....}-{1:3}, at: flushwork+0x62/0x530

Workqueue: nvmet-wq nvmetrdmareleasequeuework [nvmetrdma] Call Trace: flushwork+0x268/0x530 nvmetctrlfree+0x140/0x310 [nvmet] nvmetcqput+0x74/0x90 [nvmet] nvmetrdmafreequeue+0x23/0xe0 [nvmetrdma] nvmetrdmareleasequeuework+0x19/0x50 [nvmetrdma] processonework+0x206/0x660 workerthread+0x184/0x320 kthread+0x10c/0x240 retfromfork+0x319/0x390

Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.

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

ipv4: nexthop: allocate skb dynamically in rtmgetnexthop()

When querying a nexthop object via RTMGETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSGGOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.

This results in the following warning splat:

WARNING: net/ipv4/nexthop.c:3395 at rtmgetnexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtmgetnexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlinkrcvmsg (net/core/rtnetlink.c:6989) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) syssendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) syssendmsg (net/socket.c:2641) syssendmsg (net/socket.c:2671) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

Fix this by allocating the size dynamically using nhnlmsgsize() and using nlmsgnew(), this is consistent with nexthopnotify() behavior. In addition, adjust nhnlmsgsizegrp() so it calculates the size needed based on flags passed. While at it, also add the size of NHAFDB for nexthop group size calculation as it was missing too.

This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:

addattrl ERROR: message exceeded bound of 1048

iavf: fix out-of-bounds writes in iavfgetethtoolstats()

drm/amdgpu: prevent immediate PASID reuse case

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

net: bcmasp: fix double free of WoL irq

We do not need to free wolirq since it was instantiated with devmrequestirq(). So devres will free for us.