OESA-2026-4591: kernel security update

Q: Which systems are most likely to encounter this issue?

Systems using the OCFS2 filesystem are affected when reflinked extents are created with copy_file_range(), extents are subsequently moved or defragmented through FITRIM, and later write operations access those extents.

Q: What sequence triggers the failure?

The failure requires an extent marked as refcounted to be cached before an extent move or defragment operation clears that flag on disk. A later write can then use the stale cached flag and trigger the BUG_ON in ocfs2_refcount_cal_cow_clusters().

Q: How can administrators tell whether the issue has been encountered?

A system that reaches the vulnerable condition triggers BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) in ocfs2_refcount_cal_cow_clusters(). The relevant workload pattern involves copy_file_range(), FITRIM-driven extent movement, and subsequent writes on OCFS2.

Published Oct 29, 2026

Updated

The Linux Kernel, the operating system core itself. Security Fix(es):

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

ocfs2: clear extent cache after moving/defragmenting extents

The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUGON in ocfs2refcountcalcowclusters().

The problem occurs when: 1. copyfilerange() creates a reflinked extent with OCFS2EXTREFCOUNTED 2. ioctl(FITRIM) triggers ocfs2moveextents() 3. ocfs2moveextentsrange() reads and caches the extent (flags=0x2) 4. ocfs2moveextent()/ocfs2defragextent() calls ocfs2moveextent() which clears OCFS2EXTREFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUGON(!(rec->eflags & OCFS2EXTREFCOUNTED)) triggers

Fix by clearing the extent map cache after each extent move/defrag operation in ocfs2moveextentsrange(). This ensures subsequent operations read fresh extent data from disk.(CVE-2025-40233)

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

net: dsa: properly keep track of conduit reference

Problem description -------------------

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

There are two distinct problems.

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

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

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

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

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

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

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

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

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

History and blame attribution -----------------------------

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

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

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

ocfs2: fix out-of-bounds write in ocfs2writeendinline

KASAN reports a use-after-free write of 4086 bytes in ocfs2writeendinline, called from ocfs2writeendnolock during a copyfilerange splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF.

The root cause is that ocfs2trytowriteinlinedata trusts the on-disk idcount field to determine whether a write fits in inline data. On a corrupted filesystem, idcount can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer.

Call trace (crash path):

vfscopyfilerange (fs/readwrite.c:1634) dosplicedirect splicedirecttoactor iterfilesplicewrite ocfs2filewriteiter genericperformwrite ocfs2writeend ocfs2writeendnolock (fs/ocfs2/aops.c:1949) ocfs2writeendinline (fs/ocfs2/aops.c:1915) memcpyfromfolio <-- KASAN: write OOB

So add idcount upper bound check in ocfs2validateinodeblock() to alongside the existing isize check to fix it.(CVE-2026-43075)

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

thunderbolt: Limit XDomain response copy to actual frame size

tbxdomaincopy() copies req->responsesize bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions.

Use the minimum of frame size and expected response size for the copy length.(CVE-2026-53146)

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

mm/hugememory: update file PMD counter before folioput()

splithugepmdlocked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folioput() drops the last reference, mmcounterfile() can later read freed folio state via foliotestswapbacked().

Move the counter update before folioput().(CVE-2026-53189)

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

Bluetooth: bnep: reject short frames before parsing

A BNEP peer can send a short BNEP SDU. bneprxframe() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bneprxcontrol() also dereferences the control opcode without rejecting an empty control payload.

Use skbpulldata() for the fixed fields in bneprxframe() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads.

For BNEPSETUPCONNREQ, name the UUID-size byte before pulling the setup payload. struct bnepsetupconnreq carries destination and source service UUIDs after that byte, each uuidsize bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication.

Validation reproduced this kernel report: KASAN slab-out-of-bounds in bneprxframe.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dumpstacklvl+0xb3/0x140 (?:?) printaddressdescription+0x57/0x3a0 (?:?) bneprxframe+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) printreport+0xb9/0x2b0 (?:?) virtaddrvalid+0x1ba/0x3a0 (?:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) kasanaddrtoslab+0x21/0x60 (?:?) kasanreport+0xe0/0x110 (?:?) processonework+0xfce/0x17e0 (kernel/workqueue.c:3200) workerthread+0x65c/0xe40 (?:?) kthreadparkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) rawspinunlockirq+0x28/0x50 (?:?) retfromfork+0x586/0x870 (?:?) switchto+0x74f/0xdc0 (?:?) retfromforkasm+0x1a/0x30 (?:?)(CVE-2026-53253)

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

Bluetooth: RFCOMM: validate skb length in MCC handlers

The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers.

Fix this by using skbpulldata() to validate and access the required data before dereferencing it.

rfcommrecvrpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.(CVE-2026-53254)

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

netfilter: nfconntrack: destroy stale expectfn expectations on unregister

NAT helpers such as nfnath323 store a raw pointer to module text in exp->expectfn (e.g. ipnatq931expect). nfcthelperexpectfnunregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text.

When the expected connection arrives, initconntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nfnath323, then connecting to the expected port:

Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 initconntrack.isra.0 (net/netfilter/nfconntrackcore.c:1862) nfconntrackin (net/netfilter/nfconntrackcore.c:2049) ipv4conntracklocal (net/netfilter/nfconntrackproto.c:223) nfhookslow (net/netfilter/core.c:619) iplocalout (net/ipv4/ipoutput.c:120) tcptransmitskb (net/ipv4/tcpoutput.c:1715) tcpconnect (net/ipv4/tcpoutput.c:4374) tcpv4connect (net/ipv4/tcpipv4.c:345) sysconnect (net/socket.c:2167) Modules linked in: nfconntrackh323 [last unloaded: nfnath323]

Reaching the dangling state requires CAPSYSMODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless.

Add nfcthelperexpectfndestroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronizercu() is introduced. With the fix, the same reproducer runs to completion without the Oops.(CVE-2026-53349)

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

ntfs3: reject direct userspace writes to reserved $LX xattrs

NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into iuid, igid and imode from ntfsgetwslperm().

Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and SISUID on their own file and gain euid 0 after inode reload.

Reject direct userspace writes to the reserved $LX names. Internal ntfs3 metadata updates are unchanged because ntfssavewslperm() writes them via ntfssetea() directly.

[(CVE-2026-63833)

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

Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count

rmif3ainitialize() takes the GPIO count from the device query register (f3a->gpiocount = buf & RMIF3AGPIOCOUNT, range 0..127). rmif3amapgpios() then allocates gpiokeymap with min(gpiocount, TRACKSTICKRANGEEND) == at most 6 entries, but rmif3aattention() iterates the full gpiocount and dereferences gpiokeymap[i], and input->keycodemax is set to the full gpiocount while input->keycode points at the 6-entry allocation.

A device that reports gpiocount > 6 therefore causes an out-of-bounds read of gpiokeymap[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since inputdefaultgetkeycode() and inputdefaultsetkeycode() only bound the index against keycodemax.

Size the keymap for the full gpiocount. The mapping loop is unchanged: it still assigns only the first min(gpiocount, TRACKSTICKRANGEEND) entries; the remaining slots stay KEYRESERVED (devmkcalloc zero-fills) and are skipped when reporting.(CVE-2026-64277)

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

HID: appleir: fix UAF on pending keyuptimer in remove()

appleirremove() runs hidhwstop() before timerdeletesync(). hidhwstop() synchronously unregisters the HID input device via hiddisconnect() -> hidinputdisconnect() -> inputunregisterdevice(), which drops the last reference and frees the underlying inputdev when no userspace handle holds it open.

keyuptick() reads appleir->inputdev and calls inputreportkey() / inputsync() on it. The timer is armed from appleirrawevent() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hidhwstop() has freed inputdev but before the teardown drains it.

A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (rawevent) running during hidhwstop() can call modtimer() and re-arm the timer, which then fires after hidinputdisconnect() has freed inputdev. The same URB-completion window also lets rawevent() reach keyup(), keydown() and batteryflat() directly, all of which dereference appleir->inputdev.

Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleirremove() sets the flag under the lock and then shuts down the timer with timershutdownsync(), which both drains any in-flight callback and permanently disables further modtimer() calls. appleirrawevent() and keyuptick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->inputdev, after remove() has started tearing down.

The keyrepeat and flatbattery branches of appleirrawevent() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->currentkey in the keyrepeat branch.

This bug is structurally a sibling of commit 4db2af929279 ("HID: appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been present since the driver was introduced.(CVE-2026-64363)

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

fs/ntfs3: bound NTFSDE view.dataoff in UpdateRecordData{Root,Allocation}

In doaction()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is Add2Ptr(e, le16tocpu(e->view.dataoff)), where e->view.dataoff comes from an on-disk NTFSDE inside an INDEXROOT or INDEXBUFFER. Neither case validates view.dataoff + dlen against e->size; the existing checkifindexroot / checkifallocindex helpers walk the entry chain and validate the entry's offset, but not its internal view fields.

The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.dataoff + view.datasize <= e->size. Apply the same bound at the two memmove sites.

Reproduced under UML+KASAN on mainline 8d90b09e6741 via prwarn-only probe instrumentation: with view.dataoff forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFSDE.

This is similar in shape to Pavitra Jha's 2026-05-02 patch "fs/ntfs3: prevent oob in case UpdateRecordDataRoot" (<(CVE-2026-64532)

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

net/smc: fix UAF in smccdcrxhandler() by pinning the socket

smccdcrxhandler() looks up the connection by token under the link group's connslock, drops the lock, and then dereferences conn and the smcsock derived from it, ending in sockhold(&smc->sk) inside smccdcmsgrecv(). No reference is held across the lock release.

The only reference pinning the socket while the connection is discoverable in the link group is taken in smclgrregisterconn() (sockhold) and dropped in smclgrunregisterconn() (sockput), both under connslock. Once the handler drops connslock, a concurrent close() -> smcrelease() -> smcconnfree() -> smclgrunregisterconn() can drop that reference and free the smcsock, so the handler's later sockhold() runs on freed memory:

WARNING: lib/refcount.c:25 at refcountwarnsaturate Workqueue: rxewq dowork refcountwarnsaturate (lib/refcount.c:25) smccdcmsgrecv (net/smc/smccdc.c:430) smccdcrxhandler (net/smc/smccdc.c:502) smcwrrxtaskletfn (net/smc/smcwr.c:445) taskletactioncommon (kernel/softirq.c:938) handlesoftirqs (kernel/softirq.c:622) Kernel panic - not syncing: paniconwarn set

Only SMC-R is affected. The SMC-D receive tasklet is stopped by taskletkill(&conn->rxtsklet) in smcconnfree() before the connection is unregistered, so it cannot run concurrently with the free.

Take the socket reference while still holding connslock, so the registration reference can no longer be the last one, and drop it once the handler is done.(CVE-2026-64541)

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

Bluetooth: btrtl: validate firmware patch bounds

rtlbtparsefirmware() copies patchlength - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup.

The existing patchoffset + patchlength check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.(CVE-2026-68479)

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

ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fillmax is set

When a USB audio endpoint requests full packet transfers via the fillmax descriptor flag, dataepsetparams() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value.

Since u->buffersize is allocated as maxsize packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory.

Update maxsize to curpacksize when fillmax is set so that the allocated DMA buffer size matches the actual transfer request size.

changed to reassign maxsize only when ep->fillmax is set -- tiwai

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

Bluetooth: HIDP: validate numbered report payloads

When hidpgetrawreport() waits for a numbered report, hidpprocessdata() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed.

KMSAN reports an uninitialized-value use in hidpsessionrun(), with the value originating in allocskb() through vhciwrite(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added.

The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds.

Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.(CVE-2026-74507)

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

Bluetooth: HIDP: reject frames without a transaction header

hidprecvctrlframe() and hidprecvintrframe() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom.

KMSAN reports the use in hidpsessionrun(), with the uninitialized value originating in allocskb() through vhciwrite(). The control path produces two reports and the interrupt path produces one.

The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2caprecvacldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDPTRANSHIDCONTROL | HIDPCTRLVIRTUALCABLEUNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds.

Pull the transaction header with skbpulldata() and discard frames that do not contain it.(CVE-2026-74508)

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

net: ipv6: clear suppressed fib6 rule result

fib6rulesuppress() drops a suppressed route with ip6rtputflags(), but leaves res->rt6 pointing at the released rt6info.

If no later rule supplies a replacement, fib6rulelookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6lookup(), and the next put hits rcurefputslowpath() from dstrelease().

Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.(CVE-2026-74581)

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

net/sched: clsroute: fix fastmap use-after-free on filter

The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4filter pointers indexed by (id, iif). The reader (route4classify) populates this cache via route4setfastmap() for every classified packet that hits a filter. The writer (route4delete, route4change) clears the cache via route4resetfastmap() before RCU-deferred kfree of the filter.

This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4resetfastmap(), then tcfqueuework() 3. Reader calls route4setfastmap() and writes f into the cache after the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory

Reproduced with an mdelay(100) accelerator in route4setfastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths.

Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.(CVE-2026-74583)

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

ipv6: prevent in6devget() from resurrecting inet6dev

in6devget() reads dev->ip6ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed.

Use refcountincnotzero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller.

An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000:

refcountt: addition on 0; use-after-free. ip6mcsource+0xef4/0x17e0

It was followed by the corresponding reference underflow in ip6mcsource(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends:

BUG: KASAN: slab-use-after-free in mutexlock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219

Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.(CVE-2026-74630)

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

net/sched: clsu32: skip hash tables in u32bindclass()

u32walk() enumerates both struct tcuhnode and struct tcuknode through the walker callback. u32bindclass() unconditionally casts the passed fh to tcuknode and accesses &n->res, so when fh is actually a tcuhnode, which has no tcfresult member, this results in a slab-out-of-bounds read of res->classid in tcclsbindclass().

The issue can be reproduced with the following commands:

tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit

Fix this by skipping hash tables via the TCU32KEY(handle) check.(CVE-2026-74739)

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

inet: frags: strip GSO state from fragments before reassembly

A virtionethdr (tun/tap, or AFPACKET with PACKETVNETHDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gsotype to fragoff. inetfragreasmprepare()/inetfragreasmfinish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gsosize/gsotype/gsosegs, and chain the remaining fragments on fraglist with whatever linear/paged layout they arrived with.

After ipdefrag() (iplocaldeliver(), nfdefragipv4, ...) the reassembled skb therefore still claims to be GSO (SKBGSODODGY), and the next software segmentation point - udprcvsegment() on local delivery, validatexmitskb(), or the ipfinishoutputgso() slow path - hands it to skbsegment(). skbsegment()'s fraglist walk assumes GRO-shaped input and hits one of its BUGON()s. Two writes to a tap by an unprivileged user in its own userns are enough:

kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skbsegment+0x20ca/0x48b0 Call Trace: <TASK> udpgsosegment+0x29a/0x27d0 udp4ufofragment+0x458/0x6c0 inetgsosegment+0x429/0x1340 skbmacgsosegment+0x233/0x4f0 skbgsosegment+0x308/0x660 udpqueuercvskb+0x440/0xad0 udpunicastrcvskb+0xc7/0x2c0 udprcv+0x16ce/0x2260 ipprotocoldeliverrcu+0x197/0x2d0 iplocaldeliver+0x430/0x690 iprcv+0x16f/0x1f0 netifreceiveskbonecore+0x15e/0x1c0 netifreceiveskb+0x1e/0x110 netifreceiveskb+0xf6/0x5c0 tunrxbatched.isra.0+0x3ab/0x790 tungetuser+0x17c3/0x3550 tunchrwriteiter+0xba/0x1b0 vfswrite+0x646/0x1130 </TASK> Kernel panic - not syncing: Fatal exception in interrupt

This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAPNETRAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtionethdr to a tap. The SKBGSODODGY fraglist checks added by commit 3dcbdb134f32 ("net: gso: Fix skbsegment splat when splitting gsosize mangled skb having linear-headed fraglist") and by commit 9e4b7a99a03a ("net: gso: fix panic on fraglist with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gsosize == skbheadlen(head), which the sender controls.

An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 ("tun: Allow GSO using virtionethdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inetfragqueueinsert(), which IPv4, IPv6, nfconntrackreasm and 6lowpan reassembly share; then neither the head nor the fraglist members of the reassembled skb carry them (the members matter too: the ipdofragment()/ip6fragment() fast paths send them out as they are). The head may remain CHECKSUMPARTIAL; that is already accepted on receive and resolved by skbchecksumhelp() in ipdofragment()/ip6fragment() on forward.

Tested on top of net.git (dc4b95b8fee9), x8664: the tap reproducer above, two further IPv4 fraglist geometries that reach BUGON(i >= nfrags) and BUGON(!listskb->headfrag), and an IPv6 fragment-header variant (udp6ufofragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.(CVE-2026-80590)

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

vxlan: re-fetch eth header after routeshortcircuit()

Before routeshortcircuit(), the eth header pointer is cached from ethhdr(skb).

Inside routeshortcircuit(), pskbmaypull() can be called, which may reallocate skb->head.

In this case, returning to vxlanxmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->hdest.

Fix this by updating eth = ethhdr(skb) after calling routeshortcircuit().(CVE-2026-80681)

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

ipvs: do not propagate one-packet flag to synced conns

Synced connections can be created before their destination exists. When the destination is later added, ipvsbinddest() copies connection flags from the destination into cp->flags.

IPVSCONNFONEPACKET connections are not synced. If a synced connection inherits IPVSCONNFONEPACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conntab node, leaving stale hash nodes pointing at a freed struct ipvsconn.

Drop IPVSCONNFONEPACKET from destination flags when binding synced connections.(CVE-2026-80714)

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

slip: fix use-after-free in slsync()

slipdevs[] stores bare netdevice pointers and takes no reference on them. slsync() and slalloc() walk that table from slipopen() under rtnllock(), while an entry is dropped by slfreenetdev(), which slsetup() installs as dev->privdestructor.

privdestructor is called from netdevruntodo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop:

/ Snapshot list, allow later requests / listreplaceinit(&nettodolist, &list);

rtnlunlock(); ... if (dev->privdestructor) dev->privdestructor(dev); / slipdevs[i] = NULL / if (dev->needsfreenetdev) freenetdev(dev); ... / Free network device / kobjectput(&dev->dev.kobj);

So rtnllock() does not serialise slipopen() against the teardown at all. slsync() can load slipdevs[i] while the entry is still published and dereference it after netdevruntodo() has run the destructor and released the device:

CPU0 (slipopen) CPU1 (slipclose) unregisternetdev() rtnlunlock() netdevruntodo() rtnlunlock() rtnllock() slsync() dev = slipdevs[i] privdestructor(dev) slipdevs[i] = NULL kobjectput(&dev->dev.kobj) / dev is freed / sl = netdevpriv(dev) if (sl->tty || sl->leased) / use-after-free /

BUG: KASAN: use-after-free in slsync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slipopen+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506

CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: slsync drivers/net/slip/slip.c:730 [inline] slipopen+0xef4/0x1210 drivers/net/slip/slip.c:806 ttyldiscopen+0xa2/0x120 drivers/tty/ttyldisc.c:433 ttysetldisc+0x324/0x720 drivers/tty/ttyldisc.c:564 tiocsetd drivers/tty/ttyio.c:2428 [inline] ttyioctl+0x5f0/0x1530 drivers/tty/ttyio.c:2712

Allocated by task 6502: allocnetdevmqs+0x98/0xfe0 net/core/dev.c:10719 slalloc drivers/net/slip/slip.c:756 [inline] slipopen+0x36d/0x1210 drivers/net/slip/slip.c:817 ttyldiscopen+0xa2/0x120 drivers/tty/ttyldisc.c:433 ttysetldisc+0x324/0x720 drivers/tty/ttyldisc.c:564

Freed by task 6497: devicerelease+0xa2/0x240 drivers/base/core.c:2507 kobjectput+0x179/0x280 lib/kobject.c:729 netdevruntodo+0x6c8/0xef0 net/core/dev.c:10509 slipclose+0x166/0x1c0 drivers/net/slip/slip.c:906 ttyldiscclose+0x113/0x1a0 drivers/tty/ttyldisc.c:456 ttyldisckill+0x94/0x160 drivers/tty/ttyldisc.c:614 ttyldiscrelease+0xe3/0x2b0 drivers/tty/ttyldisc.c:782 ttyrelease+0xbcc/0xe70 drivers/tty/ttyio.c:1860

Commit e58c19124189 ("slip: Fix use-after-free Read in slipopen") fixed a different source of stale entries - a device left in slipdevs[] after slipopen() freed it on the registration error path - and does not address this race, which is why the report survives it.

Drop the entry from ndouninit instead. unregisternetdevice() calls ndouninit under RTNL, before the device is queued to netdevruntodo(), so an entry that slsync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. slfreenetdev() stays only for the slipopen() error path, where registernetdevice() may have failed before ndoinit and ndouninit is then not called either. Both running for the same device is harmless: the ---truncated---(CVE-2026-81001)

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

xdp: fix zero-copy frame layout

xdpconvertzctoxdpframe() clones an XSK packet into an order-0 page and advertises PAGESIZE as its frame size. It allows the copied frame to occupy the page tail needed by skbsharedinfo and records zero headroom even when metadata separates the frame header from packet data. An AFXDP zero-copy packet redirected through cpumap can therefore make the skb overlap skbsharedinfo or place it beyond the allocated page.

Limit the copied layout to SKBWITHOVERHEAD(PAGESIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result.

BUG: KASAN: slab-out-of-bounds in skbgroreceive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skbgroreceive (net/core/gro.c:174) udpgroreceive (net/ipv4/udpoffload.c:812) inetgroreceive (net/ipv4/afinet.c:1539) devgroreceive (net/core/gro.c:515) groreceiveskb (net/core/gro.c:633) cpumapkthreadrun (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:164) retfromforkasm (arch/x86/entry/entry64.S:255) Kernel panic - not syncing: KASAN: paniconwarn set ...(CVE-2026-81002)

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

iommu/vt-d: Force requesting ACS when tboot is enabled

Currently the conditions of requesting ACS in detectinteliommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tbootforceiommu().

Fix it by checking tboot in detectinteliommu().(CVE-2026-89448)

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

openvswitch: Fix CT limit teardown use-after-free

Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovsmutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state.

An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovsctexecute() when the netns is torn down.

Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovsmutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists.

Netns teardown detaches the RCU-protected CT limit state in the pernet .preexit callback while holding ovsmutex. The pernet core guarantees an RCU grace period between the .preexit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization.

The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.(CVE-2026-89488)

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

svcrdma: Reject Read lists that exceed the page budget

Individual Read segment lengths are validated at decode time, but nothing prevents a requester from sending multiple segments whose cumulative length exceeds the rqpages array budget. When one segment fills the page array exactly, the runtime guard in svcrdmabuildreadsegment() is bypassed because len reaches zero. A subsequent segment then accesses the NULL sentinel slot at rqpages[rqmaxpages], resulting in a NULL pointer dereference during DMA mapping.

Accumulate pages across all Read segments and reject the message at decode time when the total would overflow the page budget.(CVE-2026-89528)

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

svcrdma: Reject inline replies that overflow the pull-up buffer

An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svcrdmapullupneeded() selects pull-up and svcrdmapullupreplymsg() linearizes the whole reply into sctxt->scxprtbuf. That buffer is only scmaxreqsize bytes, while the reply on this path is bounded only by the client's request, so svcrdmaxblinearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in scsges[0].length and posted, so the device also reads beyond the mapped region.

The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMAPULLUPTHRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svcrdmapullupneeded() report -E2BIG when the reply it would pull up cannot fit scmaxreqsize, and fail the request with ERRCHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection.

The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svcrdmapullupneeded() to svcrdmacheckpullup() so its name no longer implies a boolean predicate.(CVE-2026-89530)

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

SUNRPC: fix gssxdecoptionarray error path bugs

Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded groupinfo, and a latent use-after-free that the leak fix would otherwise expose.

gssxdecoptionarray() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to freeoa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count:

gsspacceptseccontextupcall() gssxdecacceptseccontext() gssxdecoptionarray() / fails, count=1 data=NULL / data = res.options.data[0].value / NULL deref /

Independently, freecreds: releases the partially decoded svccred with a bare kfree(creds). gssxdeclinuxcreds() installs a groupsalloc() result into creds->crgroupinfo; that object is kvmalloc-backed and refcounted, and only putgroupinfo() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the groupinfo allocation.

The natural fix for the leak is to call freesvccred(creds) before kfree(creds), but freesvccred() invokes putgroupinfo() on creds->crgroupinfo unconditionally when non-NULL. The existing outfreegroups: path in gssxdeclinuxcreds() already called groupsfree() on that pointer without clearing it, so once freesvccred() is wired in, the subsequent putgroupinfo() would touch freed memory.

Fix all four together:

- Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL. - Reset oa->count to 0 at freeoa: so count and data stay coherent and the caller sees an empty option array. - Call freesvccred(creds) before kfree(creds) at freecreds: so the refcounted crgroupinfo is released. freesvccred() either NULL-guards each field explicitly (crgroupinfo has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gssmechput() which guards with if(gm) at gssmechswitch.c:342), so it is safe to call on a partially decoded svccred where only cruid/crgid/crgroupinfo have been written and everything else is zero from kzalloc. - In gssxdeclinuxcreds()'s outfreegroups: path, release crgroupinfo with putgroupinfo() rather than groupsfree() so the teardown matches freesvccred()'s refcount-aware path, and clear the pointer so a later freesvccred() on the same creds does not release it a second time.(CVE-2026-89544)

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

sunrpc: defer rqargp and rqresp free until after RCU grace period

svcrqstfree() frees rqstp->rqargp and rqstp->rqresp synchronously via kfree(), but defers the rqstp struct free via kfreercu(). After svcexitthread() calls listdelrcu() and svcrqstfree(), there is a window where RCU readers that started before listdelrcu() can still traverse the thread list and find the rqstp. These readers (e.g. nfsdnlrpcstatusgetdumpit()) dereference rqstp->rqargp, which has already been freed — a use-after-free.

Fix this by moving the kfree of rqargp and rqresp into an explicit callrcu() callback alongside the struct free. Resources not accessed by RCU readers (bvec, buffer pages, scratch folio, authdata) remain synchronously freed.(CVE-2026-89545)

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

mptcp: fix uninitialized localid in syncookie MPJOIN reconstruction

mptcptokenjoincookieinitstate() restores remotenonce, localnonce, backup, joinid, token and msk from the saved cookie entry when rebuilding the request socket for a MPJOIN 4th-ACK handled under SYN cookies, but it does not restore localid, even though the SYN path saved it. subflowulpclone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLABTYPESAFEBYRCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MPJOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection.

Restore subflowreq->localid from the cookie entry, as done for the other fields.(CVE-2026-89554)

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

ceph: fix UAF in checknewmap() on session freed during unlock

checknewmap() iterates mdsc->sessions[] and for each active session drops mdsc->mutex to perform per-session operations. The forced-close path (rank removed from map) correctly takes a reference on s via cephgetmdssession() before releasing mdsc->mutex, but three other paths do not:

Path A (address changed): mutexunlock → mutexlock(&s->smutex) Path B (reconnect): mutexunlock → sendmdsreconnect(mdsc, s) Path C (active transition): mutexunlock → mutexlock(&s->smutex)

Without the extra reference, another thread can acquire mdsc->mutex during the unlock window, call unregistersession() which drops the last reference on s, and free it. The original thread then accesses freed memory via s->smutex.

Fix by adding cephgetmdssession(s) before each mutexunlock and cephputmdssession(s) after the corresponding mutexlock, matching the pattern already used in the forced-close path.

Race timeline (Path A):

Thread A (checknewmap) Thread B (another map update holds mdsc->mutex or session teardown) -------------------------- -------------------------- s = mdsc->sessions[i] (refcount == 1, held only by sessions[] array)

mutexunlock(&mdsc->mutex) ---> acquires mdsc->mutex unregistersession(mdsc, s) sessions[i] = NULL cephputmdssession(s) refcount: 1 -> 0 kfree(s) <--- freed!

mutexlock(&s->smutex) UAF on freed s->smutex(CVE-2026-89654)

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

NFSD: Prevent lock owner use-after-free during client teardown

destroyclient() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on clownerstrhashtbl. clienthasstate() does not count a bare owner, so DESTROYCLIENTID can reach destroyclient() with such owners present.

destroyclient() then walks the table, calling removeblockedlocks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flcowner. The per-net laundromat reaps blocked locks from nn->blockedlockslru independently of client state. The two paths share blockedlockslock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as destroyclient() dereferences it, a NULL dereference in removeblockedlocks().

nfsd4releaselockowner() holds a reference across the same call; destroyclient() does not. Hold cllock across the walk, taking a reference and unhashing each owner, then drop it before removeblockedlocks() and nfs4putstateowner(), which take blockedlockslock and cllock.(CVE-2026-89662)

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

nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE

The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdrdecodesattr():

iap->iaatime.tvnsec = tmp2 NSECPERUSEC;

tmp2 is a u32 and NSECPERUSEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tvnsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tvnsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGEARGS reply. NFSv2 defines no NFSERRINVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do.

Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for "set to the current server time", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encodesattr() and xdrencodecurrentservertime() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 NSECPERUSEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric.

The decoder only applied the Sun convention in the mtime block, which clears ATTRATIMESET|ATTRMTIMESET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tvnsec (10^9) and left ATTRATIMESET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTRATIMESET so the server uses its current time and ignores the value. Only ATTRATIMESET is cleared there. The mtime block keeps its existing behavior, where 1000000 means "set both atime and mtime to now".

cel: various tweaks, addenda, and clean-ups

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

nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops

A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes cleanly into a valid uint32, but it is not a valid timespec64: tvnsec must be less than NSECPERSEC.

Nothing in the setattr path clamps it. notifychange() runs the time through timestamptruncate(), which does not reduce tvnsec below NSECPERSEC when the filesystem supports nanosecond granularity (stimegran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via inodesetctimetots()). The un-normalized value then corrupts on-disk metadata: ext4's ext4encodeextratime() shifts tvnsec left by EXT4EPOCHBITS, which overflows the 32-bit extra field and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS with bigtime mis-stores the timestamp for the same reason.

Validate the client-supplied atime/mtime in the proc handlers and return NFS3ERRINVAL before anything is changed. RFC 1813 lists NFS3ERRINVAL for SETATTR and describes it as the error for a value the server 'can not store ... in its own representation'; the client maps it to EINVAL.

Checking in the proc handlers, rather than in nfsdsetattr(), keeps the rejection in front of object creation. The create operations create the object before nfsdcreatesetattr() runs, so a late failure would leave the new object behind and turn a non-idempotent request into a namespace change that reports failure. The check is therefore done up front, for the create operations before the object is created.

tvnsec is a long, so the comparison casts it to unsigned long (the same width) rather than to u32, matching timespec64valid(). A u32 cast would truncate on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire nseconds was assigned to a 32-bit long.

Only client-supplied times are checked: SETTOSERVERTIME requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard simply never matches the object's ctime and yields NFS3ERRNOTSYNC via the existing guardtime comparison, which is the protocol-correct outcome rather than rejecting the request.(CVE-2026-89666)

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

nfsd: initialize copy-notify stateid before publishing it

nfsd4copynotify() finished initializing the cpntf state after nfs4allocinitcpntfstate() had already linked it into the s2scpstateids IDR and the parent's sccplist, with cscount == 1 (the membership reference) and none held for the caller. A racing OFFLOADCANCEL (crafted clid == nn->s2scpclid plus the guessable soid) could reach managecpntfstate() and free the entry, turning the caller's subsequent cpncnrstateid read and cppstateid/cppclid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window.

Record cppstateid and cppclid inside nfs4allocinitcpntfstate() before nfs4initcpstate() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4putcpntfstate(); on a late error the laundromat reaps the entry.(CVE-2026-89669)

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

nfsd: gate nfs3 setacl by argp->mask

nfsd3procsetacl() calls setposixacl() unconditionally for both ACLTYPEACCESS and ACLTYPEDEFAULT, passing argp->aclaccess and argp->acldefault verbatim. The NFSv3 ACL decoder only populates those pointers when the corresponding mask bit is set:

nfs3svcdecodesetaclargs() if (args->mask & NFSACL) decode into aclaccess if (args->mask & NFSDFACL) decode into acldefault / otherwise the pointer stays NULL (pcargzero) /

nfsd3procsetacl() setposixacl(.., ACLTYPEACCESS, argp->aclaccess) setposixacl(.., ACLTYPEDEFAULT, argp->acldefault)

setposixacl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation. A NULL pointer that means "the client did not send this arm" is therefore indistinguishable from "the client asked to remove this ACL". A SETACL with mask=NFSACL silently drops the directory's default ACL; mask=0 drops both.

The sibling nfsd3procgetacl() already consults argp->mask before touching each arm; mirror that in setacl.

Fix by wrapping each setposixacl() call in the matching mask bit check and initializing error to 0 before inodelock so that a request with neither bit set leaves the on-disk ACLs untouched and returns nfsok. The outdroplock path and the unconditional posixaclrelease() at out: are preserved; both NULL-tolerate the skipped arms.(CVE-2026-89671)

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

nfsd: fix XDR length calculation in nfsd4ffencodelayoutget

The XDR buffer size calculation in nfsd4ffencodelayoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client:

- fhlen doesn't account for XDR padding on the file handle data - uid and gid lengths use "8 + len" but xdrencodeopaque() actually writes "4 + xdralignsize(len)" bytes - dslen omits the flags and statscollecthint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch

The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client.

Fix this by breaking out every encoded field explicitly in the dslen calculation, using xdralignsize() for all variable-length opaque fields, and correcting the header constants.(CVE-2026-89674)

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

nfsd: fix UAF in async copy cancel and shutdown

An async copy could be freed or used after free while a teardown caller (OFFLOADCANCEL, nfsd4shutdowncopy, nfsd4cancelcopybysb) raced the copy kthread:

- findasynccopy() bumped copy->refcount but left the copy on clp->asynccopies, so the reaper's cleanupasynccopy() could run releasecopyfiles() concurrently with a cancel/shutdown caller. Both put and NULL nfsrc/nfdst without a common lock, double-putting the nfsdfile and freeing it early.

- nfsd4doasynccopy() set NFSD4COPYFSTOPPED before its final uses of the copy (nfsdupdatecmtimeattr() on copy->nfdst, nfsd4sendcboffload()). nfsd4stopcopy() treats a set STOPPED bit as "kthread done, skip kthreadstop()", so a teardown caller ran releasecopyfiles() -- which puts and NULLs nfdst -- while the kthread still dereferenced it (NULL/UAF).

- copy->copytask was never pinned. The one-shot kthread self-reaps on return, so kthreadstop()'s gettaskstruct() could touch a freed taskstruct.

- cocb is embedded in the copy, but nfsd4sendcboffload() held a reference only on the client, so a concurrent teardown could free the copy while the CBOFFLOAD callback was in flight.

Fix the teardown lifetime as a whole:

- findasynccopy() unlinks the copy (clear cpclp, listdelinit) under asynclock; the cancel, shutdown, and sb-cancel paths drop the list-membership reference via nfs4putcopy() after nfsd4stopcopy(). Drop the now-redundant listdel fixup from cleanupasynccopy().

- Because unlinking hides the copy from the reaper, its cleanupasynccopy() can no longer remove the copy's s2scpstateids entry; the cancel/shutdown/sb-cancel paths now call nfs4freecopystate() themselves (while cpclp is still valid) so the entry does not dangle at freed memory for the laundromat and managecpntfstate() to dereference.

- Give the kthread its own reference, taken in nfsd4copy() before wakeupprocess() and dropped at the end of nfsd4doasynccopy(); call wakeupprocess() before listadd().

- Pin the taskstruct with gettaskstruct() in nfsd4copy(), released in nfs4putcopy(), so kthreadstop() is safe whenever the kthread exits. Set NFSD4COPYFSTOPPED only in nfsd4stopcopy(), which now always kthreadstop()s before releasecopyfiles(); completion is still reported via NFSD4COPYFCOMPLETED, so nfsd4hasactiveasynccopies() is unaffected. Each teardown caller removes the copy from clp->asynccopies first, so kthreadstop() runs exactly once.

- Take a copy reference in nfsd4sendcboffload(), dropped in nfsd4cboffloadrelease(). The kthread still holds its own reference there, so the refcountinc() cannot race the final free.

- Read cpclp with smploadacquire() to pair with the unordered setbit()/clearbit() writers (Documentation/atomicbitops.rst).(CVE-2026-89675)

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

nfsd: fix nfsdfile leak on inter-server COPY setup failure

When nfsd4setupinterssc() fails, nfsd4copy() returns nfserroffloaddenied directly, bypassing the out: label where releasecopyfiles() would drop the nfdst reference taken by nfs4preprocessstateidop(). Each failed inter-server COPY leaks one nfsdfile, pinning file/inode/dentry/vfsmount.

Fix by setting status and jumping to out: instead of returning directly.(CVE-2026-89680)

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

nfsd: fix clock domain mismatch in clientsstillreclaiming()

clientsstillreclaiming() computes a deadline from nn->boottime (CLOCKREALTIME, ~1.7 billion) but compares it against ktimegetboottimeseconds() (CLOCKBOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline.

This means any client can hold the server in grace indefinitely by sending CLAIMPREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients.

Add boottimebt (CLOCKBOOTTIME) alongside the existing boottime and use it for the deadline computation. boottime (CLOCKREALTIME) is preserved for its clboot clientid-nonce role.(CVE-2026-89685)

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

nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref

When CONFIGNFSDV42INTERSSC is enabled, nfsd4putfh() can return success with fhdentry and fhexport both NULL if fhverify() returns nfserrstale and putfh->noverify is true. The NFSD4FHFOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserrnofilehandle check -- it does not prevent subsequent ops from running with a NULL fhdentry.

A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes checkifstalefhallowed() to set noverify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fhwantwrite() which dereferences fhexport->expath.mnt without calling fhverify() first, causing a NULL pointer dereference in the nfsd kthread.

Fix this by gating the dispatch loop: when NFSD4FHFOREIGN is set and fhdentry is NULL, only OPSAVEFH (needed for the inter-SSC flow) and ops with ALLOWEDWITHOUTFH (which don't need a resolved filehandle) may proceed. All other ops receive nfserrstale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERRSTALE returned at that point.(CVE-2026-89696)

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

lockd, nfsd: RCU-protect nlmsvcops dispatch

nlmsvcops is published by nfsdlockdinit() and cleared by nfsdlockdshutdown() with plain stores, while lockd dereferences it unguarded from dispatch sites in fs/lockd/svcsubs.c. The pointer targets nfsd's .rodata and the fopen/fclose callbacks live in nfsd's .text, so a stale load after rmmod nfsd results in either a NULL deref or a module-text use-after-free.

Declare nlmsvcops as rcu, publish via rcuassignpointer(), clear via RCUINITPOINTER() + synchronizercu(). Add a struct module owner field to nlmsvcbinding and pin the module across indirect calls with trymoduleget/moduleput. When the binding is torn down, fall back to fput() to avoid leaking struct file references.(CVE-2026-89709)

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

scsi: qla2xxx: Initialize NVMe abortwork once at submission

qlanvmefcpabort() and qlanvmelsabort() ran INITWORK() on priv->abortwork immediately before schedulework(). INITWORK() reinitializes the workstruct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INITWORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker.

Initialize priv->abortwork once at command submission, next to the existing per-command spinlockinit(&priv->cmdlock), and leave only schedulework() in the abort paths. schedulework() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final krefput()/release callback runs after abortwork has completed, so the work item is idle before priv is reused and the single submission-time INITWORK() is safe.(CVE-2026-89860)

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

NFSv4.2: fix LAYOUTSTATS send buffer exhaustion

encodelayoutstatsmaxsz budgets XDRQUADLEN(PNFSLAYOUTSTATSMAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that.

fflayoutencodefflayoutupdate() emits, per data server, a netaddr4, an nfsfh4, two ffiolatency4, an nfstime4 and a bool. A data server whose filehandle is NFSMAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ffiolatency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encodelayoutstats() additionally writes the deviceid4 and the layoutupdate4 loutype word, neither of which the macro accounts for.

The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdrreservespace() returns NULL once that happens, and the two fflayoutencodeiolatency() calls run with dssinfo->mirror->lock held, so a NULL return there leaves the lock permanently held.

Raise PNFSLAYOUTSTATSMAXSIZE to 384 so that the record fits inside the reservation.(CVE-2026-90103)

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

wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length

The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARNONONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when paniconwarn is set.

Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf ("mt76x2: remove some harmless WARNONs in tx status and rx path") did for the neighboring rx and tx status paths.

Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.(CVE-2026-90382)

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

powerpc/xive: propagate IPI init errors to prevent use-after-free

When xiveinitipis() fails (e.g. irqdomainallocirqs() fails), the error path frees the global xiveipis array. However, xivesmpprobe() previously ignored this failure and proceeded to call xivesetupcpuipi(), which dereferences the already-freed xiveipis pointer -- a use-after-free.

Now that xivesmpprobe() returns int (previous patch), propagate the error from xiveinitipis() and xivesetupcpuipi() through xivesmpprobe(). Check the return value in both pnvsmpprobe() and pSeriessmpprobe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free.(CVE-2026-93260)

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

perf: Fix addrfilterranges lifetime

Lee Jia Jie reported that since event::addrfilterranges is used under RCU, it should be RCU freed.(CVE-2026-93817)

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

HID: hidpp: fix potential UAF in hidppconnectevent()

If inputregisterdevice() fails, we call inputfreedevice(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidppconnectevent().(CVE-2026-93826)

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

ACPICA: add boundary checks in two places

Add boundary checks in acpipsgetnextnamestring() and acpipspeekopcode() to prevent out-of-bounds access.(CVE-2026-97444)

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

ACPICA: Enhance buffer validation in acpiutwalkamlresources()

Enhance buffer validation in acpiutwalkamlresources() to prevent buffer overflows.(CVE-2026-97445)

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

ACPICA: Add validation for node in acpinsbuildnormalizedpath()

Add validation for node in acpinsbuildnormalizedpath() to prevent use-after-free vulnerabilities.(CVE-2026-97448)

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

ACPICA: validate handler object type in two places

ACPICA: validate handler object type in acpievhasdefaulthandler() and acpievfindregionhandler().(CVE-2026-97450)

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

ACPICA: Fix integer overflow in acpiexopcode3A1T1R() (midop)

Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().(CVE-2026-97451)

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

ACPICA: Prevent adding invalid references

Prevent adding references for local, argument, and debug objects in acpiutcopysimpleobject().(CVE-2026-97452)

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

ACPICA: add boundary checks in acpipsgetnextfield()

Add boundary checks in acpipsgetnextfield() to prevent out-of-bounds access.(CVE-2026-97454)

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

ACPICA: Fix use-after-free in acpidsterminatecontrolmethod()

Fix use-after-free issue in acpidsterminatecontrolmethod() by clearing references to method locals and arguments.(CVE-2026-97455)

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

scsi: qla2xxx: Skip vport under deletion in report ID acquisition

qla24xxreportidacquisition() format-1 handling walks ha->vplist under vportslock, takes a vrefcount on the matching vport and calls qlaupdatehostmap() to register its port id.

A vport teardown via qla24xxvportdelete() sets VPORTDELETE, then qla24xxdisablevp() removes the vport from the hostmap btree and zeroes vha->did (RESETALPA). The vport is only unlinked from vplist later, in qla24xxdeallocatevpid(), which clears vpmap[idx] (RESETVPIDX) but does not touch hostmap. In the window in between, report ID acquisition can still find the vport on vplist and call qlaupdatehostmap(); with did already zeroed it takes the btreeinsert32() path and re-inserts the dying vport into hostmap. Nothing cleans that entry afterwards, so once scsihostput() frees the vha a later hostmap lookup dereferences freed memory.

Skip a vport that has VPORTDELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00alertallvps().(CVE-2026-97531)

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

scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown

The response queue MSI-X handler qla2xxxmsixrspq() schedules qladowork() via queuework(ha->wq, &qpair->qwork). qladowork() dereferences the qpair (vha, rsp) and takes qpair->qplock.

During teardown, qla2xxxdeleteqpair() deletes the response queue, which calls freeirq() in qla25xxfreerspque(), and then frees the queue and the qpair. freeirq() waits for running hardirq handlers but does not cancel work already placed on ha->wq. A still-pending qwork then runs qladowork() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroyworkqueue(ha->wq) forces pending work to run after the queue pairs have been freed.

Flush the work item with cancelworksync() in qla25xxfreerspque() after freeirq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq to match the INITWORK() condition and avoid operating on an uninitialized workstruct.(CVE-2026-97536)

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

media: v4l2-ctrls: validate HEVC tile counts

The stateless HEVC decoders read numtilecolumnsminus1 + 1 entries from columnwidthminus1[] and numtilerowsminus1 + 1 from rowheightminus1[] and use them as tile-loop bounds, but stdvalidatecompound() does not bound these u8 counts. Reject a V4L2CTRLTYPEHEVCPPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.(CVE-2026-97576)

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

net: mpls: clear innerprotocol when the last label is popped

skbmplspush() records the pre-encapsulation network header once, gated on !skb->innerprotocol. skbmplspop() never clears that record, so it outlives the encapsulation it describes.

Open vSwitch can then re-push MPLS onto a packet whose innernetworkheader still points at the older, deeper offset: push a label, pop every label, recirculate (ovsflowkeyupdate() re-derives key->eth.type and resets networkheader, but leaves inner), then push again. ovsfragment() trusts the record:

skb->networkheader = skb->innernetworkheader;

so skbnetworkoffset() goes negative. The bound check is signed:

if (skbnetworkoffset(skb) > MAXL2LEN)

a negative offset passes it, and preparefrag() widens the value:

unsigned int hlen = skbnetworkoffset(skb); memcpy(&data->l2data, skb->data, hlen);

which is a ~4GiB memcpy out of a 30-byte per-CPU buffer.

Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8):

BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 preparefrag+0x3df/0x4e0 ovsfragment+0x589/0x7e0 dooutput+0x4ce/0x5e0 doexecuteactions+0x55d2/0x7b30 ovsexecuteactions+0xea/0x450

Same root-cause shape as commit 975b5b067f52 ("ipv6: sr: restore network header before routing and forwarding"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path.

Clear innerprotocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/actmpls.c is the only other skbmplspop() caller and gets the same fix; schfrag.c saves and restores innerprotocol around fragmentation in the same way OVS does.(CVE-2026-97612)

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

tracing: Set the trace clock before registering the histogram trigger

histregistertrigger() puts the trigger on the global namedtriggers list in cmdops->init(), and only then sets the trace clock:

if (data->cmdops->init) { ret = data->cmdops->init(data); if (ret < 0) goto out; }

if (histdata->enabletimestamps) { ret = tracingsetclock(file->tr, histdata->attrs->clock); if (ret) { histerr(tr, HISTERRSETCLOCKFAIL, errpos(clock)); goto out; }

The clock string is not checked anywhere before that call, so a named trigger using commontimestamp with an unknown clock fails after it has already become findable. eventhisttriggerparse() then frees it without taking it off the list, and the next lookup by name reads the freed object:

~# cd /sys/kernel/tracing/events/sched/schedswitch ~# echo 'hist:name=foo:keys=commonpid:ts=commontimestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=commonpid' > trigger

BUG: KASAN: slab-use-after-free in findnamedtrigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 findnamedtrigger+0xac/0xc0 histregistertrigger+0xc1/0x900 eventhisttriggerparse+0x3146/0x6af0 eventtriggerwrite+0xce/0x160 Freed by task 63: kfree+0x154/0x420 triggerkthreadfn+0xfd/0x160

Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting namedtriggers list") moved the registration below the rest of the setup.

tracingsetfilterbuffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first.(CVE-2026-97935)

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

ipv6: fix fib6 walker UAF on seq stop

ipv6routeiteractive() treats a walker in FWSU at the table root as already unlinked. fib6delroute() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6routenativeseqstop() skips fib6walkerunlink(). The seq private object can then be freed while it remains on net->ipv6.fib6walkers. A later route deletion walks the dangling list and uses the freed walker.

Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked.

The same stop helper is used by /proc/net/ipv6route and by the BPF ipv6route iterator. The BPF show path only widens the race.(CVE-2026-97940)

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

bpf: Don't predict JMP32 pointer vs zero comparisons

Consider the following program:

r1 = mapvalue; / low 32 bits are zero at runtime / r6 = 0xdead000000000000; if w1 != 0 goto l1; l0: r1 += r6; r2 = (u64 )(r1 + 0); exit; l1: r6 = 0; goto l0;

At the moment isbranchtaken() reports the jump as always taken, because it does not distinguish between BPFJMP and BPFJMP32 comparisons when processing 'if w1 != 0 ...'.(CVE-2026-98041)

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

nvme: remove stale namespaces by NSID range during scan

nvmescannslist() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvmefindgetns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present.

NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove.

watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvmescanwork [nvmecore] RIP: 0010:srcureadunlock+0xb/0x20 Call Trace: nvmefindgetns+0x7d/0xb0 [nvmecore] nvmescannslist+0xe8/0x280 [nvmecore] nvmescanwork+0x18a/0x280 [nvmecore] processonework+0x197/0x380 workerthread+0x2fe/0x410 kthread+0xe0/0x100

Rename nvmeremoveinvalidnamespaces() to nvmeremovensidrange() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap.(CVE-2026-98056)

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

ipv6: sr: restore network header before routing and forwarding

ipv6srhrcv() runs with skb->data at the Segment Routing Header (SRH) while skbnetworkheader() points at the IPv6 header.

When segmentsleft > 0, ipv6srhrcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skbnetworkoffset() remained negative.

This led to two problems: 1. During ip6routeinput(), fib6rulesearlyflowdissect() invokes skbflowdissect() which passes the negative skbnetworkoffset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6forward() or redirected via actmirred, downstream handlers (like schfragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows.

Fix this by pushing -skbnetworkoffset(skb) before routing, ensuring skbnetworkoffset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skbtransportoffset(skb) to restore skb->data to the SRH before looping back.(CVE-2026-98096)

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

Bluetooth: L2CAP: fix chan mode for LECONNREQ + EXTFLOWCTL pchan

l2capnewconnection() sets default value of channel mode to match the parent channel. l2capleconnectreq() left this at the default, and created L2CAPMODEEXTFLOWCTL channels if listening pchan has that mode. This causes FLAGDEFERSETUP channels to reply to L2CAPLECONNREQ with L2CAPECREDCONNRSP, which is incorrect.

It can also result to stack OOB write (of l2capalloccid determined values) in l2capecredrspdefer(), as l2capleconnectreq() does not limit maximum number of deferred channels or check for duplicate ident.

Fix by setting chan->mode correctly in l2capleconnectreq().

Also check channel mode in l2capecredrspdefer(), and do WARNONONCE instead of OOB write to make it less brittle.(CVE-2026-98108)

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

KEYS: encrypted: fix integer overflow of databloblen

encryptedkeyalloc() stores databloblen in a u16. It is computed from multiple string and payload lengths. If the result exceeds U16MAX, the assignment truncates the allocation size. KASAN reports a 32760-byte slab-out-of-bounds write when ekeyinit() copies the master key description into the undersized buffer.

The total payload length stored in key->datalen is also a u16. Use checkaddoverflow() to reject values that do not fit either destination, and use kzallocflex() for the flexible-array allocation.(CVE-2026-98222)

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

RDMA/core: fix refcount bug in iwpmgetnlmsgrequest()

iwpmgetnlmsgrequest() initializes refcount after listaddtail() making it accessible to global list where another CPU can krefget() on nlmsgrequest causing a refcount "addition on 0" bug. Fix this by initializing kref before listaddtail() so refcount for nlmsgrequest can be incremented/decremented normally. In addition, also initialize every field before listaddtail().(CVE-2026-98252)

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

RDMA/ucma: Serialize join and leave on copytouser failure

rdmajoinmulticast() queues RoCE work that later reads the ucmamulticast through event->param.ud.privatedata, then listadd()s the CMA multicast at the head of idpriv->mclist. rdmaleavemulticast() matches only by sockaddr and destroys the first hit.

ucmaprocessjoin() used to drop ctx->mutex after a successful join and retake it only if copytouser() failed. Two concurrent JOINMCAST calls with the same address can therefore insert a second CMA entry before the first thread's leave. leave then cancels the newer work and the older worker still dereferences the ucmamulticast that the first thread frees.

Keep ctx->mutex held from rdmajoinmulticast() through copytouser() and, on -EFAULT, through rdmaleavemulticast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mclist, and a leave-by-addr would destroy an earlier successful join.(CVE-2026-98253)

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

net: lock the socket in sockgettstamp()

sk->skflags must only be changed while holding the socket lock, because socksetflag() and sockresetflag() use non atomic operations (setbit() and clearbit()).

sockgettstamp() is one of the last places where a bit of sk->skflags is changed from a syscall without owning the socket lock, through sockenabletimestamp(sk, SOCKTIMESTAMP).

sksetmemalloc() and skclearmemalloc() also change sk->skflags without the socket lock, but their callers (nbd, iscsitcp, nvme-tcp, sunrpc, wireguard) need a careful audit, this will be addressed in a separate patch.

Jungwoo Lee and Wongi Lee reported an UDP socket use-after-free caused by this bug: a SIOCGSTAMPNSNEW ioctl racing with bind() can cancel the SOCKRCUFREE bit that udplibgetport() just set, because both threads perform a read-modify-write on the same word.

CPU 0 (bind) CPU 1 (SIOCGSTAMPNSNEW) -------------------------------- ---------------------------- read skflags = F read skflags = F compute F | BIT(SOCKRCUFREE) compute F | BIT(SOCKTIMESTAMP) store F | BIT(SOCKRCUFREE) skaddnodercu(sk, ...) store F | BIT(SOCKTIMESTAMP)

After the lost update, SOCKRCUFREE is clear while the socket is visible to lockless UDP receive lookups. skdestruct() then frees the socket immediately instead of waiting for a RCU grace period, while the receive path still holds a reference-less pointer to it:

BUG: KASAN: slab-use-after-free in ipv4pktinfoprepare+0x30/0x410 Read of size 8 at addr ffff888008806610 by task exploit/207 CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1 ipv4pktinfoprepare+0x30/0x410 udpqueuercvoneskb+0x51c/0x1180 udpunicastrcvskb+0x109/0x350 ipprotocoldeliverrcu+0x14b/0x310 iplocaldeliverfinish+0x29d/0x390 iplocaldeliver+0x24d/0x2a0

Only grab the socket lock when SOCKTIMESTAMP has to be set, to keep the common case lockless.(CVE-2026-98276)

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

IB/isert: wait for deferred control PDU completions before releasing the connection

isertsenddone() hands ISTATESENDTASKMGTRSP, ISTATESENDREJECT and ISTATESENDTEXTRSP completions off to isertcompwq and returns. The work item then runs isertcompletionput() -> isertputcmd(), which reads isertconn->conn and takes conn->cmdlock.

Nothing orders that work item against teardown. isertwaitconn() queues isertreleasework, which frees isertconn, and iscsitcloseconnection() frees the iscsitconn right after it returns, so the queued work can run against freed memory.

Count the deferred control PDU completions per connection and let isertwaitconn() wait for them before the release work is queued.

ISTATESENDLOGOUTRSP is deliberately not counted: that branch runs iscsitlogoutposthandler(), which ends up waiting for conn->connwaitcomp, and that completion is only sent by iscsitcloseconnection() after it has called iscsitwaitconn(). Waiting for it here would deadlock. Its wait stays the existing isertwait4logout().

The splat below is from a kernel with tracing printk()s and an msleep(200) injected into isertdocontrolcomp() to widen the window:

BUG: KASAN: slab-use-after-free in isertputcmd+0x53d/0x620 Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182

CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy) Tainted: [B]=BADPAGE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: isertcompwq isertdocontrolcomp Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xd0/0x630 ? pfxrawspinlockirqsave+0x10/0x10 ? rawspinunlockirqrestore+0x3e/0x70 ? isertputcmd+0x53d/0x620 kasanreport+0xce/0x100 ? isertputcmd+0x53d/0x620 isertputcmd+0x53d/0x620 ? isertcompletionput+0x305/0x330 ? isertdocontrolcomp+0x2ef/0x310 processonework+0x633/0x1030 ? assignwork+0x11d/0x370 workerthread+0x45b/0xd10 ? pfxworkerthread+0x10/0x10 ? pfxworkerthread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalcsigpending+0x15c/0x1e0 ? pfxkthread+0x10/0x10 retfromfork+0x36e/0x5a0 ? pfxretfromfork+0x10/0x10 ? switchto+0x572/0xdd0 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 48: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasankmalloc+0x8f/0xa0 kmalloccachenoprof+0x158/0x370 isertcmahandler+0x1e3/0x2ae0 cmacmeventhandler+0x3e/0x240 cmaibreqhandler+0x17d9/0x4490 cmprocesswork+0x41/0x330 cmworkhandler+0x5727/0xc160 processonework+0x633/0x1030 workerthread+0x45b/0xd10 kthread+0x2c6/0x3b0 retfromfork+0x36e/0x5a0 retfromforkasm+0x1a/0x30

Freed by task 184: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x43/0x70 kfree+0x121/0x380 iscsitcloseconnection+0x7cf/0x1e60 iscsittakeactionforconnectionexit+0x1b6/0x360 iscsitargettxthread+0x472/0x690 kthread+0x2c6/0x3b0 retfromfork+0x36e/0x5a0 retfromforkasm+0x1a/0x30(CVE-2026-98357)

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

RDMA/core: Reject unregistering netdevs in ibgetethspeed

ibdevicegetnetdev() intentionally returns a referenced netdevice even when it is unregistering, so matching and cleanup callers can still find the association. The reference keeps struct netdevice allocated, but does not guarantee that the device remains operational.

ibgetethspeed() uses the returned device operationally by invoking its ethtool callback. Although that call is made under RTNL, the function does not verify the registration state first. An asynchronous RDMA port query can therefore call into a netdev after NETDEVUNREGISTER and ndouninit have completed.

Check for NETREGREGISTERED while holding RTNL and return -ENODEV for a device which is being unregistered. Keeping RTNL across the check and the ethtool operation prevents unregister from starting between them.

Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete.(CVE-2026-98359)

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

RDMA/rxe: Fix integer overflow in mrcheckrange() leading to OOB access

mrcheckrange() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic:

if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length)

A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxemriovatoindex() then computes a huge index (int idx, only guarded by WARNON) and rxemrcopyxarray() dereferences mr->pageinfo[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer.

Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow:

if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length)

With the fix, mrcheckrange() returns -EINVAL for the crafted iova and the responder reports REMOTEACCESSERROR instead of triggering the OOB.(CVE-2026-98365)

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

ipv4: validate checksumstart before completing checksum

If a packet with bad checksum metadata gets into the ipv4 stack, skbchecksumhelp can corrupt the network header and cause a bunch of mischief.

This was discovered and reported by Paulos, and has been reporoduced by others independently since.

We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum.

A more complete validation at input is forthcoming, but needs more work.(CVE-2026-99999)

Affected Software

1 affected componentFixes available

openeuler/kernel<5.10.0-339.0.0.240.oe2203sp4

5.10.0-339.0.0.240.oe2203sp4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade openeuler/kernel to a version that resolves this vulnerability.
Fixed in 5.10.0-339.0.0.240.oe2203sp4

Event History

Oct 29, 2026

Advisory Published

via OSV·09:03 AM

Data Sourced

via OSV·09:03 AM

DescriptionSeverityAffected Software

Child vulnerabilities

Contains the following vulnerabilities.

CVE-2025-40233
CVE-2025-71152
CVE-2026-43075
CVE-2026-53146
CVE-2026-53189
CVE-2026-53253
CVE-2026-53254
CVE-2026-53349
CVE-2026-63833
CVE-2026-64277
CVE-2026-64363
CVE-2026-64532
CVE-2026-64541
CVE-2026-68479
CVE-2026-74498
CVE-2026-74507
CVE-2026-74508
CVE-2026-74581
CVE-2026-74583
CVE-2026-74630
CVE-2026-74739
CVE-2026-80590
CVE-2026-80681
CVE-2026-80714
CVE-2026-81001
CVE-2026-81002
CVE-2026-89448
CVE-2026-89488
CVE-2026-89528
CVE-2026-89530
CVE-2026-89544
CVE-2026-89545
CVE-2026-89554
CVE-2026-89654
CVE-2026-89662
CVE-2026-89665
CVE-2026-89666
CVE-2026-89669
CVE-2026-89671
CVE-2026-89674
CVE-2026-89675
CVE-2026-89680
CVE-2026-89685
CVE-2026-89696
CVE-2026-89709
CVE-2026-89860
CVE-2026-90103
CVE-2026-90382
CVE-2026-93260
CVE-2026-93817
CVE-2026-93826
CVE-2026-97444
CVE-2026-97445
CVE-2026-97448
CVE-2026-97450
CVE-2026-97451
CVE-2026-97452
CVE-2026-97454
CVE-2026-97455
CVE-2026-97531
CVE-2026-97536
CVE-2026-97576
CVE-2026-97612
CVE-2026-97935
CVE-2026-97940
CVE-2026-98041
CVE-2026-98056
CVE-2026-98096
CVE-2026-98108
CVE-2026-98222
CVE-2026-98252
CVE-2026-98253
CVE-2026-98276
CVE-2026-98357
CVE-2026-98359
CVE-2026-98365
CVE-2026-99999

Frequently Asked Questions

Which systems are most likely to encounter this issue?

Systems using the OCFS2 filesystem are affected when reflinked extents are created with copy_file_range(), extents are subsequently moved or defragmented through FITRIM, and later write operations access those extents.

What sequence triggers the failure?

The failure requires an extent marked as refcounted to be cached before an extent move or defragment operation clears that flag on disk. A later write can then use the stale cached flag and trigger the BUG_ON in ocfs2_refcount_cal_cow_clusters().

How can administrators tell whether the issue has been encountered?

A system that reaches the vulnerable condition triggers BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) in ocfs2_refcount_cal_cow_clusters(). The relevant workload pattern involves copy_file_range(), FITRIM-driven extent movement, and subsequent writes on OCFS2.

OESA-2026-4591: kernel security update

Affected Software

Remediation

Event History

Child vulnerabilities

Frequently Asked Questions

Which systems are most likely to encounter this issue?

What sequence triggers the failure?

How can administrators tell whether the issue has been encountered?

Company

Resources

Contact

Frequently Asked Questions

Which systems are most likely to encounter this issue?

What sequence triggers the failure?

How can administrators tell whether the issue has been encountered?