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

wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash

When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[].

Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76dmaaddbuf+0x124/0x188 [mt76] lr : mt76dmarxfill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76dmaaddbuf+0x124/0x188 [mt76 (HASH:1029 4)] mt76dmarxreset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921wpdmareset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921emacreset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921macresetwork+0xac/0x1a8 [mt7921common (HASH:f721 6)] processonework+0x188/0x514 workerthread+0x12c/0x300 kthread+0x140/0x1fc retfromfork+0x10/0x30

Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bushung flag in mt7921macresetwork() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses.

Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled.

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

wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement

The flow is added to dev->twtlist before sending the agreement to the firmware, but the error path leaves it linked while flowidmask is never set. The flow slot can then be reused and memset while still on the list, corrupting twtlist, and station removal leaves a dangling entry behind that mt7915mactwtschedlistadd() later walks.

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

nvme-apple: Destroy the admin queue on removal

The admin queue is allocated with blkmqallocqueue() but never destroyed. nvmefreectrl() only drops the last reference and blkmqexitqueue() and blksyncqueue() never run: the hctx is never moved to q->unusedhctxlist and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blkmqtimeoutwork().

This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before.

Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvmeuninitctrl().

With this the following WARN followed by a panic no longer happens:

WARNING: block/blk-mq.c:4390 at blkmqrelease+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq applenvmeremovedeadctrlwork pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blkmqrelease+0x194/0x238 lr : blkmqrelease+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blkmqrelease+0x194/0x238 (P) blkputqueue+0x8c/0xf0 nvmefreectrl+0x4c/0x260 devicerelease+0x44/0x128 kobjectput+0xa0/0x120 putdevice+0x1c/0x40 nvmeuninitctrl+0x48/0x60 applenvmeremove+0x54/0xb0 platformremove+0x28/0x40 deviceremove+0x54/0x98 devicereleasedriverinternal+ devicereleasedriver+0x20/0x38 applenvmeremovedeadctrlwor processonework+0x1f4/0x770 workerthread+0x1b8/0x360 kthread+0x140/0x160 retfromfork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):inunlockirqrestore+0x74/0x80 hardirqs last disabled at (448): [<ffffc000811cf5c0>] el1brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blkmqtimeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpureftrygetmany.cons lr : percpureftrygetmany.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---

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

smb: smbdirect: free completion queues with ibfreecq()

smbdirectconnectiondestroyqp() creates the send and receive completion queues with iballoccqany(), which for IBPOLLWORKQUEUE arms an internal completion handler that runs ibcqpollwork() on a workqueue. Tearing those CQs down with ibdestroycq() frees them without first cancelling that poll work.

If the provider posts a completion late -- for example Soft-RoCE (rxe) posting an RNR error from rxereceiver() after rdmadestroyqp() -- the handler re-queues ibcqpollwork() on the already-freed CQ, and a follow-on access faults in rxereqnotifycq().

Use ibfreecq(), which cancelworksync()es the poll work before freeing the CQ, so no completion handler can run against a freed queue.

[ 1236.599526] ================================================================== [ 1236.602142] BUG: KASAN: slab-use-after-free in ibcqpollwork+0xd0/0x1a0 [ 1236.605524] Read of size 8 at addr ffff888111865800 by task kworker/4:1H/82 [ 1236.609017] [ 1236.609270] CPU: 4 UID: 0 PID: 82 Comm: kworker/4:1H Not tainted 7.2.0-rc3-next-20260717-virtme #110 PREEMPT(lazy) [ 1236.609287] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 1236.609498] Workqueue: ib-comp-wq ibcqpollwork [ 1236.609525] Call Trace: [ 1236.609536] <TASK> [ 1236.609545] dumpstack+0x21/0x60 [ 1236.609562] dumpstacklvl+0xc2/0x100 [ 1236.609573] printaddressdescription+0x77/0x200 [ 1236.609587] ? ibcqpollwork+0xd0/0x1a0 [ 1236.609597] printreport+0x58/0x70 [ 1236.609607] kasanreport+0x117/0x150 [ 1236.609623] ? ibcqpollwork+0xd0/0x1a0 [ 1236.609636] ? processscheduledworks+0x954/0x1600 [ 1236.609650] ibcqpollwork+0xd0/0x1a0 [ 1236.609662] ? processscheduledworks+0x954/0x1600 [ 1236.609674] processscheduledworks+0xc22/0x1600 [ 1236.609698] ? pfxprocessscheduledworks+0x10/0x10 [ 1236.609713] ? pfxassignwork+0x10/0x10 [ 1236.609726] ? lockisheldtype+0x7b/0x110 [ 1236.609741] workerthread+0x975/0xee0 [ 1236.609757] ? pfxdorawspinlock+0x10/0x10 [ 1236.609775] ? kthreadparkme+0x21e/0x260 [ 1236.609789] kthread+0x3a6/0x490 [ 1236.609800] ? pfxworkerthread+0x10/0x10 [ 1236.609809] ? pfxkthread+0x10/0x10 [ 1236.609820] retfromfork+0x55a/0xa20 [ 1236.609835] ? pfxretfromfork+0x10/0x10 [ 1236.609850] ? pfxkthread+0x10/0x10 [ 1236.609861] retfromforkasm+0x1a/0x30 [ 1236.609880] </TASK> [ 1236.609886] [ 1236.661292] Allocated by task 5076: [ 1236.662640] kasansavetrack+0x3e/0x80 [ 1236.663842] kasankmalloc+0x72/0x90 [ 1236.664763] kmallocnoprof+0x2b0/0x5d0 [ 1236.665356] iballoccq+0x284/0x1000 [ 1236.666573] iballoccqany+0x23e/0x340 [ 1236.668654] smbdirectconnectioncreateqp+0x6f7/0x1070 [ 1236.669757] smbdirectacceptconnectrequest+0x500/0x1ca0 [ 1236.672625] smbdirectlistenrdmaeventhandler+0x1655/0x1c50 [ 1236.673930] cmalistenhandler+0x1bf/0x260 [ 1236.674923] cmacmeventhandler+0x128/0x380 [ 1236.676926] cmaibreqhandler+0x2d3d/0x4de0 [ 1236.678368] cmprocesswork+0xb0/0x530 [ 1236.680454] cmqueueworkunlock+0xb1/0x230 [ 1236.681673] cmworkhandler+0x969f/0xdca0 [ 1236.682704] processscheduledworks+0xc22/0x1600 [ 1236.683447] workerthread+0x975/0xee0 [ 1236.685901] kthread+0x3a6/0x490 [ 1236.688164] retfromfork+0x55a/0xa20 [ 1236.689522] retfromforkasm+0x1a/0x30 [ 1236.690073] [ 1236.690378] Freed by task 5137: [ 1236.692242] kasansavetrack+0x3e/0x80 [ 1236.694272] kasansavefreeinfo+0x40/0x50 [ 1236.695514] kasanslabfree+0x3a/0x60 [ 1236.696773] kfree+0x14e/0x4e0 [ 1236.697216] ibdestroycquser+0x18d/0x250 [ 1236.699817] smbdirectconnectiondestroyqp+0xf2/0x280 [ 1236.702115] smbdirectsocketdestroysync+0x1607/0x2720 [ 1236.704062] smbdirectsocketrelease+0x140/0x280 [ 1236.705286] smbdirectfreetranspor ---truncated---

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

drm/xe: Reject page faults from non-fault-mode scratch VMs

Having scratch enabled does not make a VM capable of handling recoverable page faults. Allowing scratch VMs through the ASID lookup also admits dma-fence mode VMs.

If such a VM faults on an already valid VMA, the handler reports success without fixing the fault, causing the GPU to retry indefinitely.

Only allow fault-mode VMs through the ASID lookup. Fault-mode VMs using scratch remain supported, while faults from 3D VMs are rejected.

(cherry picked from commit bfb24a06405b652d37831f3fb66b71d33a6605de)

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

mm/hugememory: transfer the pmd dirty bit to the folio on zap

zaphugepmdfolio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zappresentfolioptes() and so does the pmd split path, in splithugepmdlocked().

For most file mappings the omission is harmless, because writing to a shared file mapping goes through pagemkwrite(), which dirties the folio. tmpfs is different: it has no pagemkwrite(), and vmawantswritenotify() is false for it, so a read fault on a MAPSHARED tmpfs mapping installs a writable pmd via doreadfault(). doreadfault() does not call faultdirtysharedpage(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call foliomarkdirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmemgetfoliogfp()), so PGdirty is never set at all.

Unmapping such a folio - munmap(), or exitmmap() when the process dies - then loses the only record that it was written, because zaphugepmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrinkfoliolist() is inside "if (foliotestdirty(folio))", so pageout() is skipped and the folio falls into removemapping(). There, folioisfilelru() is false for a swapbacked folio, so no shadow entry is created and filemapremovefolio(folio, NULL) simply empties the ipages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio.

This is silent data loss for any process that keeps state in a MAPSHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped.

Reproduced on x8664 with a tmpfs mounted huge=withinsize: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way.

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

power: supply: ab8500fg: fix use-after-free on remove

ab8500fgremove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue.

Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply externalpowerchanged callback) can requeue them.

Found by an in-house static analysis tool.

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

mm/vmscan: report RCU-tasks quiescent states in shrinklruvec()

I am seeing some rcutasks stalls in the Meta fleet during reclaim.

INFO: rcutasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idlecpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrinklruvec memcgroupiter shrinknode dotrytofreepages trytofreepages allocfrozenpagesnoprof allocpagesnoprof pteallocone ptealloc handlemmfault

Nothing promises direct reclaim returns in bounded time, and the scan loop in shrinklruvec() only calls condresched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout.

Upgrade it to condreschedtasksrcuqs(), which reports a quiescent state even when condresched() does nothing.

PS: This has been discussed in [1]

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

Revert "media: v4l2-dev: fix error handling in videoregisterdevice()"

This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a.

The intentions of that patch were good, but it doesn't work.

The idea is that if deviceregister fails, you have to do a putdevice to let the ref counter release resources.

However, the V4L2 API says that if videoregisterdevice() fails, then you have to call videodevicerelease(), which kfree()s the videodevice struct.

But the putdevice() will already have freed the struct, so you end up in a double-free scenario.

There is not really a good way of fixing this without breaking videoregisterdevice() into two parts, one that initializes everything, and one that does the actual deviceregister, and then converting all V4L2 drivers to this new model.

That is a massive job, and it is very unlikely that deviceregister will fail.

So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.

fs/ntfs3: fix info-leak on partial LZNT decompress in nireadframe()

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

accel/rocket: fix NULL dereference and integer overflow in rocketjobpush()

rocketjobpush() allocates a temporary array to hold all input and output GEM object pointers:

bos = kvmallocarray(job->inbocount + job->outbocount, sizeof(void ), GFPKERNEL); memcpy(bos, job->inbos, job->inbocount sizeof(void )); memcpy(&bos[job->inbocount], job->outbos, ...);

Two bugs exist:

1. Missing NULL check: if kvmallocarray() fails, bos is NULL and the subsequent memcpy() dereferences it, causing a kernel NULL pointer dereference.

2. Integer overflow: inbocount and outbocount are both u32, set directly from userspace-supplied inbohandlecount and outbohandlecount with no prior validation. Their sum is computed in u32 arithmetic and can wrap to a smaller value, causing the allocation count passed to kvmallocarray() to be smaller than intended. Subsequent uses still operate on the original counts when copying and locking objects, which may lead to out-of-bounds accesses on the temporary array.

Fix by using checkaddoverflow() to detect count overflow before the allocation, and adding a NULL check on the allocation result.

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

net/iucv: filter frames in afiucvhsrcv() by ingress device

afiucvhsrcv() selects a socket from iucvsklist by matching four 8-byte name fields in the transport header alone. No check is made against the netdevice the frame arrived on.

This can cause a frame arriving on any netdev to be delivered to an AFIUCV socket. Three problems follow.

First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hsdev == NULL. iucvsockbind() takes the classic path whenever the requested userid matches iucvuserid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucvhscallbacksyn() for such a match inherits hsdev = NULL and transport = AFIUCVTRANSHIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable.

Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections

Third, all AFIUCV sockets live in initnet, as iucvsockalloc() calls skalloc(&initnet, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAPNETRAW capability valid within that namespace can send a raw ETHPAFIUCV frame on its own lo device and have it matched against initnet sockets.

Fix all three by skipping any socket whose hsdev does not match the ingress device. A classic z/VM IUCV socket has hsdev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hsdev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hsdev is always a device in initnet (iucvsockbind() scans foreachnetdevrcu(&initnet, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket.

Note that AFIUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.

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

seg6: reset IP6CB after IPv6 decapsulation

decapandvalidate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags.

End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet.

The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6protocoldeliverrcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports:

BUG: KASAN: slab-out-of-bounds in ip6protocoldeliverrcu ip6protocoldeliverrcu+0x1118/0x1450 ip6inputfinish+0x11b/0x240 seg6localinputcore+0xed/0x2e0 lwtunnelinput+0x1e9/0x4e0 ipv6rthdrrcv+0x525f/0x6c50 ip6protocoldeliverrcu+0xcb7/0x1450

Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field.

Use IP6CB(skb)->iif rather than skb->skbiif because VRF processing can replace skbiif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKBL3SLAVE for the same reason.

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

wifi: rtl8xxxu: fix use-after-free from rxurbwq on stop

rtl8xxxu arms rxurbwq from the RX completion path: rtl8xxxurxcomplete() hands the URB to rtl8xxxuqueuerxurb(), which queues it on rxurbpendinglist and, once the list grows past RTL8XXXURXURBPENDINGWATER, schedules rxurbwq. The worker rtl8xxxurxurbwork() drains rxurbpendinglist, recovers priv through containerof, and resubmits each URB through rtl8xxxusubmitrxurb(), which anchors it on rxanchor and dereferences priv->udev.

rtl8xxxustop() cancels the sibling work items (c2hcmdwork, rawatchdog, updatebeaconwork) but never cancels rxurbwq, so a worker armed during the last burst of RX traffic can run rtl8xxxurxurbwork() after rtl8xxxudisconnect() has called ieee80211freehw(), which frees priv, producing a use-after-free. The window opens under active RX traffic (pending count above the watermark) followed by a disconnect.

There are two teardown races to close:

rtl8xxxuqueuerxurb() decided whether to enqueue under rxurblock but called schedulework() after dropping the lock. A completion that observed shutdown == false and released the lock could then call schedulework() after rtl8xxxustop() had set shutdown and cancelworksync() had already returned, arming the worker to run after the teardown. Move schedulework() under the same !shutdown branch so the arming decision is atomic with the shutdown check.

rtl8xxxurxurbwork() anchors every URB it drained back onto rxanchor through rtl8xxxusubmitrxurb(). A worker still running when usbkillanchoredurbs(&priv->rxanchor) returned would submit a URB that escaped the kill. In rtl8xxxustop(), call cancelworksync(&priv->rxurbwq) before the kill so the worker is drained first.

After priv->shutdown is set under rxurblock, completions can no longer queue rxurbwq. cancelworksync() then drains the last queued or running worker, and the following usbkillanchoredurbs() kills the URBs it may have submitted.

rtl8xxxudisconnect() is covered because ieee80211unregisterhw() guarantees .stop() runs for a live interface before ieee80211freehw() frees priv. The probe error path needs no cancel: rxurbwq is INITWORK()'d there but cannot have been scheduled, since no URB is submitted before ieee80211registerhw() succeeds.

This bug was found by static analysis.

Do we need an LLM agent to dig through the reports and give a summary where the vulnerabilities lie and what the mitigation would be?

Am Mon, 7 Sep 2026 20:29:16 -0700 schrieb Yuan Tan <yuant () nebusec ai>: We found a Linux kernel local privilege escalation vulnerability in the RDS zerocopy send path, tracked as CVE-2026-43502. We call the exploit ZcopyReaper.

CONFIGINET=y   CONFIGAIO=y   CONFIGRDS=y or m   CONFIGRDSTCP=y or m Good. Another obscure networking feature that I didn't know of and which yields system exploitation. Locking kernel module loading after boot has paid of many times now! In addition to CVE-2026-43502, there are 20 other Linux bugs that have been confirmed to be exploitable, with public exploits available: Now, need I worry or not? What can I do? I checked out the repo and did some guessing:

$ for f in Linux-CVE-2026-; do echo === $f ===; (cd $f && find . -type f |xargs grep unshare); done < === Linux-CVE-2026-23274-kernelCTF === ./exploit.c:void unsharesetup(); ./exploit.c: unsharesetup(); ./exploit.c:void unsharesetup() { ./exploit.c: SYSCHK(unshare(CLONENEWUSER)); ./exploit.c: SYSCHK(unshare(CLONENEWNET | CLONENEWNS)); ./exploit.c: unsharesetup(); ./exploit.c: unsharesetup();

Needs network namespaces.

=== Linux-CVE-2026-31659-Arch-6.19.10 === ./exploit.c: if (unshare(CLONENEWUSER | CLONENEWNET) < 0) ./exploit.c: die("unshare(CLONENEWUSER|CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-31678-Fedora-6.19.10-300 === ./exploit.c: if (unshare(CLONENEWNS) < 0) ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET)); ./exploit-v104-crosscpu-flush-trace.c: if (unshare(CLONENEWUSER) < 0) ./exploit-v104-crosscpu-flush-trace.c: die("unshare(CLONENEWUSER)"); ./exploit-v104-crosscpu-flush-trace.c: if (unshare(CLONENEWNET) < 0) ./exploit-v104-crosscpu-flush-trace.c: die("unshare(CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-43042-Debian-6.12.101 === ./utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-43501-kernelCTF === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare(CLONENEWUSER)"); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare(CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-43502-openSUSE-6.4.0-150600 ===

??????

=== Linux-CVE-2026-52912-Fedora-6.19.10-300 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare(CLONENEWUSER)"); ./exploit.c: if (unshare(CLONENEWNET | CLONENEWNS) < 0) ./exploit.c: die("unshare(CLONENEWNET|CLONENEWNS)"); ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52923-RHEL-6.12.0-211.7.3.el102 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare user"); ./exploit.c: if (unshare(CLONENEWIPC) < 0) ./exploit.c: die("unshare ipc"); ./exploit.c: if (unshare(CLONENEWIPC) < 0) ./exploit.c: die("unshare(victim ipc)"); ./exploit.c: if (unshare(CLONENEWIPC) < 0) ./exploit.c: die("unshare(trigger ipc)"); ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52924-Arch-6.19.10 === ./trigger.c: if (unshare(CLONENEWUSER | CLONENEWNET) < 0) ./trigger.c: die("unshare user+net"); ./utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52924-ubuntu-7.0.0-28 === ./trigger.c: if (unshare(CLONENEWUSER) < 0) ./trigger.c: die("unshare user"); ./trigger.c: if (unshare(CLONENEWNET) < 0) ./trigger.c: die("unshare net"); ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52929-Ubuntu-7.0.0-28 ===

????

=== Linux-CVE-2026-52933-Fedora-6.19.10-300 ===

????

=== Linux-CVE-2026-63834-Arch-6.19.10 === ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-68162-Ubuntu-7.0.0-28 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare user: %s", strerror(errno)); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare net: %s", strerror(errno)); ./exploit.c: if (unshare(CLONENEWNS) < 0) ./exploit.c: die("unshare mount namespace: %s", strerror(errno));

Needs network namespaces.

=== Linux-CVE-2026-68376-Ubuntu-7.0.0-30 === ./exploit.c: if (unshare(CLONENEWUSER)) ./exploit.c: die("unshare user"); ./exploit.c: if (unshare(CLONENEWNET)) ./exploit.c: die("unshare net");

Needs network namespaces.

=== Linux-CVE-2026-72137-ubuntu-7.0.0-28 ===

????

=== Linux-CVE-2026-72255-Ubuntu-7.0.0-28 === ./trigger.c: if (unshare(CLONENEWUSER) < 0) ./trigger.c: die("unshare(CLONENEWUSER)"); ./trigger.c: if (unshare(CLONENEWNET | CLONENEWNS) < 0) ./trigger.c: die("unshare(CLONENEWNET|CLONENEWNS)"); ./trigger.c: if (patternindex && unshare(CLONENEWNET) < 0) ./trigger.c: die("unshare(next network namespace)");

Needs network namespaces.

=== Linux-CVE-2026-74480-RHEL-6.12.0-211.7.3.el102 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare userns"); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare netns");

Needs network namespaces.

=== Linux-CVE-2026-74581-Debian-6.12.101 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare user"); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare net");

Needs network namespaces.

=== Linux-CVE-2026-74597-Centos-10-6.12.0-264 === ./exploit.c: if (unshare(CLONENEWUSER)) ./exploit.c: die("unshare(CLONENEWUSER)"); ./exploit.c: if (unshare(CLONENEWNET)) ./exploit.c: die("unshare(CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-80714-Debian-6.12.101 === ./exploit.c: CHECK(unshare(CLONENEWUSER), "unshare user"); ./exploit.c: CHECK(unshare(CLONENEWNET), "unshare net");

Needs network namespaces.

So this drives home the point that (unprivileged) network namespaces are something that will stay forbidden on my systems. What a can of worms that is!

But there is a number of exploits that get away without that:

=== Linux-CVE-2026-43502-openSUSE-6.4.0-150600 === === Linux-CVE-2026-52929-Ubuntu-7.0.0-28 === === Linux-CVE-2026-52933-Fedora-6.19.10-300 === === Linux-CVE-2026-72137-ubuntu-7.0.0-28 ===

Someone got the time to dig out what those are about?

Alrighty then,

Thomas

-- Dr. Thomas Orgis HPC @ Universität Hamburg

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

wifi: mt76: mt7925: ensure tx headroom in usbsdiotxprepareskb

mt7925usbsdiotxprepareskb() pushes a TX descriptor and a USB header onto every skb and assumes the headroom for them is already there. That holds for locally generated traffic, where mac80211 reserves hw->extratxheadroom, but forwarded frames are sent through ieee802118023xmit(), which does not reserve it. Bridge a wired interface to an mt7925u AP and the first forwarded frame that arrives short panics the kernel:

skbuff: skbunderpanic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skbpanic+0x58/0x60 (P) skbpush+0x58/0x60 mt7925usbsdiotxprepareskb+0xf8/0x1b8 [mt7925common] mt76utxqueueskb+0xa0/0x1f8 [mt76usb] mt76txqueueskb+0x54/0xe8 [mt76] mt76txqschedule.part.0+0x204/0x478 [mt76] mt76txqscheduleall+0x50/0x80 [mt76] mt792xtxworker+0x68/0x100 [mt792xlib] mt76workerfn+0x84/0x150 [mt76]

Whether a given setup hits it depends on how much headroom the ingress netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging onboard ethernet to a Netgear A9000; originally reported on an MT7986 router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet), which leaves more headroom, helped narrow the trigger to the ingress path.

The same bug was fixed on mt7921 by commit 98c4d0abf5c4 ("mt76: mt7921: don't assume adequate headroom for SDIO headers"), but mt7925 was copied from mt7921 without the fix. Add the same guard here.

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

net: gro: properly validate BIG TCP aggregation criteria

When GRO attempts to aggregate packets beyond GROLEGACYMAXSIZE (64KB), BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP (with sufficient MAC header room to insert the temporary HBH jumbo header).

However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp") loosened the check in skbgroreceive(), leading to several issues:

1. skbgroreceive() checked skbheadroom(p) instead of the actual space before the MAC header (p->macheader). Because skbheadroom(p) includes maclen, crafted frames (e.g. injected via AFPACKET) can pass the check with p->macheader < 8 bytes. When ipv6grocomplete() inserts the temporary HBH jumbo header, the memmove() starts before skb->head, causing an out-of-bounds write and wrapping skb->macheader. 2. It allowed non-IP protocols such as software VLAN (ETHP8021Q / ETHP8021AD) to aggregate beyond 64KB because p->protocol != ETHPIPV6 was true. 3. It checked p->encapsulation instead of NAPIGROCB(skb)->encapmark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB.

Fix skbgroreceive() to strictly enforce: - NAPIGROCB(skb)->proto == IPPROTOTCP - Not encapsulated (!NAPIGROCB(skb)->encapmark && !p->encapsulation) - Protocol must be either ETHPIP or ETHPIPV6 - If ETHPIPV6, p->macheader must be at least sizeof(struct hopjumbohdr)

Returning -E2BIG from skbgroreceive() ensures that packets which cannot become BIG TCP are cleanly flushed at <= 64KB and delivered intact without dropping.

This issue does not exist in mainline (7.0+) because the subsystem was rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX side"), making this fix relevant only for older stable branches like 6.18.y.

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

Bluetooth: hcisync: Fix advertising data UAFs

hcifindadvinstance() returns an advinfo pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response.

An advertising termination event can therefore interleave as follows:

hcicmdsyncwork hcirxwork hcifindadvinstance() hcicmdsyncstatus() wait for controller reply hcidevlock() hciremoveadvinstance() kfree(adv) adv->scanrspchanged = false

KASAN reported:

BUG: KASAN: slab-use-after-free in hcisetextscanrspdatasync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hcicmdsyncwork Call Trace: hcisetextscanrspdatasync+0x2e1/0x300 hcischeduleadvinstancesync+0x390/0x4c0 hcicmdsyncwork+0x173/0x300 Allocated by task 87: hciaddadvinstance+0x538/0xac0 addadvertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hciremoveadvinstance+0x1d8/0x3b0 hcileextadvtermevt+0x17b/0x730

Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller.

Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No advinfo pointer then survives an HCI command wait.

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

crypto: atmel-sha204a - fix blocking and non-blocking rng logic

The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message.

Tested on an Atmel SHA204A device.

Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020

After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020

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

nvme-pci: fix out-of-bounds access in nvmesetupdescriptorpools

nvmesetupdescriptorpools() indexes dev->descriptorpools[] using the numanode forwarded from hctx->numanode by its single caller, nvmeinithctxcommon(). On a non-NUMA kernel hctx->numanode is NUMANONODE (-1). Because the parameter was declared 'unsigned', the value becomes UINTMAX and the index walks off the array (sized to nrnodeids), faulting during nvmeallocns() and leaving the namespace without a /dev node.

Reproduces on any NVMe controller probed by a CONFIGNUMA=n kernel:

BUG: unable to handle page fault for address: ffff889101603d38 RIP: 0010:nvmeinithctxcommon+0x5a/0x190 [nvme] Call Trace: nvmeinithctx+0x10/0x20 [nvme] nvmeallocns+0x9e/0xa10 [nvmecore] nvmescanns+0x301/0x3b0 [nvmecore] nvmescannsasync+0x23/0x30 [nvmecore]

Switch the parameter to int and fall back to node 0 when it is NUMANONODE; node 0 is always present.

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

crypto: marvell/octeontx - fix DMA cleanup using wrong loop index

The sgcleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.

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

handshake: Require admin permission for DONE command

ACCEPT and DONE are the two downcalls of the handshake genl family, both intended for use by the trusted handshake agent (tlshd). ACCEPT already requires GENLADMINPERM; DONE has no privilege check at all.

The fd-lookup in handshakenldonedoit() only confirms that some pending handshake request exists for the supplied sockfd; it does not authenticate the sender. An unprivileged process that guesses or observes a valid sockfd can therefore submit a DONE with HANDSHAKEADONESTATUS == 0, leaving the kernel consumer to proceed as if the handshake succeeded. A non-zero status on a forged DONE tears down a legitimate in-flight handshake before tlshd can report its real result.

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

net: serialize netifrunning() check in enqueuetobacklog()

Syzbot reported a KASAN slab-use-after-free in fibruleslookup().

The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit).

Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netifrunning() check in enqueuetobacklog() to prevent queuing packets to an unregistering device.

However, this creates a TOCTOU race window.

A lockless transmitter (like vethxmit) can pass the check before devclose() clears IFFUP. If the transmitter is then delayed, flushallbacklogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed.

Fix this by moving the netifrunning() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netifrunning() after the flush/close completes (so it gets dropped).

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

perf/x86/amd/core: Avoid enabling BRS from the SVM reload path

Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbrusers.

When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amdpmuenableall() to rewrite the event selectors. However, amdpmuenableall() also calls amdbrsenableall(), which enables BRS whenever cpuc->lbrusers > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP:

Call Trace: <IRQ> amdpmuenableall+0x1d/0x90 amdpmudisablevirt+0x62/0xb0 kvmarchdisablevirtualizationcpu+0xa/0x40 [kvm] hardwaredisablenolock+0x1a/0x30 [kvm] flushsmpcallfunctionqueue+0x9b/0x410 sysveccallfunction+0x18/0xc0 sysveccallfunction+0x69/0x90 </IRQ> <TASK> asmsysveccallfunction+0x16/0x20 RIP: 0010:cpuidleenterstate+0xc4/0x450 ? cpuidleenterstate+0xb7/0x450 cpuidleenter+0x29/0x40 cpuidleidlecall+0xf5/0x160 doidle+0x7b/0xe0 cpustartupentry+0x26/0x30 startsecondary+0x115/0x140 secondarystartup64noverify+0x194/0x19b </TASK>

Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbrusers > 0.

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

gpio: mvebu: free generic chips on unbind

irqallocdomaingenericchips() allocates generic chip data that must be freed via irqdomainremovegenericchips(). The devres action mvebugpioremoveirqdomain() only called irqdomainremove(), which only frees the generic chips if IRQDOMAINFLAGDESTROYGC is set. Call irqdomainremovegenericchips() explicitly before irqdomainremove() instead.

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

batman-adv: frag: free unfragmentable packet

The caller of batadvfragsendpacket() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions.

A failed pre-check must use the same error handling code as the rest of the function.

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

mm/damon/core: always put unsuccessfully committed target pids

damoncommittarget() puts and gets the destination and the source target pids. It puts the destination target pid because it will be overwritten by the source target pid. It gets the source pid because the caller is supposed to eventually put the pids. In more detail, the caller will call damondestroyctx() after damoncommitctx() to destroy the entire source context. And in this case, [f]vaddr operation set's cleanuptarget() callback will put the pids.

The commit operation is made at the context level. The operation can fail in multiple places including in the middle and after the targets commit operations. For any such failures, immediately the error is returned to the damoncommitctx() caller. If some or all of the source target pids were committed to the destination during the unsuccessful context commit attempt, those pids should be put twice.

The source context will do the put operations using the above explained routine. However, let's suppose the destination context was not originally using [f]vaddr operation set and the commit failed before the ops of the source context is committed. The destination does not have the cleanuptarget() ops callback, so it cannot put the pids via the damondestroyctx().

As a result, the pids are leaked. The issue in the real world would be not very common. The commit feature is for changing parameters of running DAMON context while inheriting internal status like the monitoring results. The monitoring results of a physical address range ain't have things that are beneficial to be inherited to a virtual address ranges monitoring. So the problem-causing DAMON control would be not very common in the real world. That said, it is a supported feature. And damoncommittarget() failure due to memory allocation is relatively realistic [1] if there are a huge number of target regions.

Fix by putting the pids in the commit operation in case of the failures.

The issue was discovered [2] by Sashiko.

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

wifi: libertastf: fix use-after-free in lbtffreeadapter()

lbtffreeadapter() calls timerdelete(&priv->commandtimer), which does not wait for a running commandtimerfn() callback. lbtffreeadapter() runs on the teardown path right before ieee80211freehw() frees priv, both in lbtfremovecard() and in the probe error path. commandtimer is armed by modtimer() in lbtfcmd() whenever a firmware command is sent. commandtimerfn() dereferences priv. If a command times out as the device is removed, commandtimerfn() runs concurrently with teardown and dereferences priv after it has been freed.

This is the same use-after-free that commit 03cc8f90d053 ("wifi: libertas: fix use-after-free in lbsfreeadapter()") fixed in the sibling libertas driver. The libertastf variant has the identical pattern and was left unchanged. Use timerdeletesync() so any in-flight callback completes before priv is freed.

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

smp: Make CSD lock acquisition atomic for debug mode

Commit b0473dcd4b1d ("smp: Improve smpcallfunctionsingle() CSD-lock diagnostics") changed smpcallfunctionsingle() so that, when CSD lock debugging is enabled, async !wait calls use the destination CPU csddata. That improves diagnostics, but it also removes the single-writer property that made the old csdlock() safe: multiple CPUs can now prepare the same destination CPU CSD concurrently.

csdlock() currently waits for CSDFLAGLOCK to clear and then sets the bit with a non-atomic read-modify-write. Two senders can both see an unlocked CSD, set the bit, overwrite the callback fields, and enqueue the same llist node. Re-adding a node that is already the queue head can make node->next point to itself, leaving the target CPU stuck walking callsinglequeue. Later synchronous work, such as a TLB shootdown, can then remain queued and trigger soft-lockup warnings or panics.

Keep the single csdlock() implementation, but when CSD lock debugging is enabled, acquire CSDFLAGLOCK with trycmpxchgacquire(). This makes the destination CPU CSD a real atomic lock in the only configuration where it can be shared by multiple remote senders, while preserving the existing non-debug fast path.

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

xfrm: clear mode callbacks after failed mode setup

xfrmstategctask can run long after a failed IPTFS state setup. In the reproduced case, xfrminitstate() cached x->modecbs, IPTFS setup returned -ENOMEM before publishing modedata, and the temporary module reference from xfrmgetmodecbs() was dropped immediately. The dead state then kept x->modecbs until deferred GC ran after xfrmiptfs had been unloaded.

Clear x->modecbs when mode init or clone fails before publishing modedata. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference.

The buggy scenario involves two paths, with each column showing the order within that path:

failed setup path: 1. cache x->modecbs 2. mode setup fails before modedata 3. drop the temporary module ref 4. dead state keeps x->modecbs cached

GC/unload path: 1. xfrmstateput() queues GC work 2. xfrmiptfs unloads later 3. xfrmstategctask runs 4. GC dereferences stale x->modecbs

This also covers the failed clone path where clonestate() returns before publishing modedata.

Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIGFAULTINJECTIONSTACKTRACEFILTER=y failslabstacktracefilter matched xfrmiptfs frames ackerror=-12 FAULTINJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrmstategctask RIP: xfrmstategctask+0x142/0x650 Modules linked in: esp4offload xfrmuser [last unloaded: xfrmiptfs] Kernel panic - not syncing: Fatal exception