OESA-2026-4718: kernel security update

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

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

can: esdusb: kill anchored URBs before freeing netdevs

esdusbdisconnect() frees each CAN netdev with freecandev() inside its per-netdev loop and only calls unlinkallurbs(dev) afterwards. The per-netdev private data (struct esdusbnetpriv) is embedded in the netdevice allocation returned by alloccandev(), so once freecandev() has run, dev->nets[i] points to freed memory. unlinkallurbs() then dereferences the freed dev->nets[i] to kill the per-netdev TX anchor (usbkillanchoredurbs(&priv->txsubmitted)), clear activetxjobs, and reset priv->txcontexts[].

Reorder the teardown so the anchored URBs are killed before the netdevs are freed, matching other CAN/USB drivers in the same directory such as emsusb, usb8dev and mcbausb, which unregister, then unlink, then free: unregister the netdevs first (which stops their TX queues), call unlinkallurbs(dev) once, then free the netdevs.

This issue was found by an in-house static analysis tool.(CVE-2026-64585)

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

ocfs2: avoid moving extents to occupied clusters

For non-auto OCFS2IOCMOVEEXT operations, userspace supplies a physical megoal. ocfs2moveextent() initializes newphyscpos from that goal and expects ocfs2probeallocgroup() to replace it with a free run in the target block group.

The probe currently leaves physcpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to ocfs2moveextent(), which copies file data into a cluster still owned by another inode before the bitmap is updated.

When the probe does find a free run, it also subtracts movelen from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run.

Clear physcpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.(CVE-2026-72164)

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

ntfs: fix off-by-one in mapping pairs decoding bounds checks

In ntfsmappingpairsdecompress(), attrend points one byte past the end of the attribute record:

attrend = (u8 )attr + le32tocpu(attr->length);

The two bounds checks validating that mapping pair data bytes fit within the attribute use strict greater-than (>), which allows a one-byte out-of-bounds read when the data extends exactly to attrend:

b = buf & 0xf; if (b) { if (unlikely(buf + b > attrend)) // off-by-one goto ioerror; for (deltaxcn = (s8)buf[b--]; b; b--) deltaxcn = (deltaxcn << 8) + buf[b]; }

When buf + b == attrend, the check evaluates to false and buf[b] reads one byte past the valid attribute boundary. The same pattern appears in the LCN delta bytes check.

Fix both checks to use >= so that buf[b] at exactly attrend is correctly rejected as out of bounds.(CVE-2026-72210)

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

ASoC: codecs: hdachdmi: Validate written enum value

hdachdmisetpinportmux() uses the written enum value to index the texts array before calling sndsocdapmputenumdouble(), which validates that the value is within the enum item range.

An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.(CVE-2026-74295)

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

net/smc: fix qentry overwrite for CONFIRMLINK and ADDLINKCONT in smcllceventhandler()

The SMCLLCCONFIRMLINK / SMCLLCADDLINKCONT branch in smcllceventhandler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRMLINK or ADDLINKCONT request while a flow is active and flow->qentry is already set, smcllcflowqentryset() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message.

The sibling SMCLLCDELETELINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRMLINK/ADDLINKCONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation.

The response direction (smcllcrxresponse()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.(CVE-2026-74719)

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

vsock/virtio: flush works in dependency order

virtiovsockremove() stops the virtqueues and then flushes each work item before freeing the enclosing virtiovsock. The current order does not account for dependencies between those items: txwork may queue sendpktwork, and sendpktwork may queue rxwork.

In particular, sendpktwork can set restartrx and release txlock. The remove path can then stop the queues and flush rxwork before sendpktwork queues it. Although the later sendpktwork flush waits for that producer to finish, nothing waits for the newly queued rxwork, so kfree(vsock) can race with it.

KASAN reported:

BUG: KASAN: slab-use-after-free in virtiotransportrxwork+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtiovsock virtiotransportrxwork Call Trace: virtiotransportrxwork+0x487/0x4b0 processonework+0x688/0x1120 workerthread+0x45b/0xd10 Allocated by task 1: virtiovsockprobe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtiovsockremove+0xd1/0x100

Flush the works in producer-to-consumer order. virtiovsockvqsdel() has already disabled the queue callbacks and cleared the run flags, so after txwork and sendpktwork are drained, no source remains that can queue rxwork after its flush.(CVE-2026-80932)

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

net/smc: stop killed, freed and outofsync sharing a byte

The three connection state flags are single-bit bitfields, so they occupy one byte of struct smcconnection and every store to one is a read-modify-write of the other two:

u8 killed : 1; u8 freed : 1; u8 outofsync : 1;

They are not written under a common lock. smccdcmsgvalidate() sets outofsync from the receive tasklet, while smcconnkill() sets killed from process context under locksock(), and the receive path does not defer to the backlog when the socket is owned -- smccdcmsgrecv() takes only bhlocksock().

Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smcconnection grows by two bytes.(CVE-2026-80980)

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

sctp: fix stream->outcnt underflow on duplicate RECONF responses

A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADDOUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it.

Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.(CVE-2026-89476)

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

fs/ntfs3: fix out-of-bounds read of INDEXROOT in reparse/objid init

ntfsreparseinit() and ntfsobjidinit() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEXROOT attributes named $R and $O). They read its type and rule fields through residentdata(), which does not check that the resident attribute is large enough to hold them.

mienumattr() accepts a resident attribute with dataoff == asize and datasize == 0. For such an attribute placed last in its MFT record, residentdata() returns a pointer to the end of the recordsize buffer, so reading root->type / root->rule reads past the allocation.

Use residentdataex(attr, sizeof(struct INDEXROOT)) and bail out when it returns NULL, as ntfssecurityinit() already does for $SDH / $SII.

The attribute is only parsed while mounting a crafted image, so this needs CAPSYSADMIN.

BUG: KASAN: slab-out-of-bounds in ntfsreparseinit (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfsreparseinit (fs/ntfs3/fsntfs.c:2306) ntfsfillsuper (fs/ntfs3/super.c:1604) gettreebdevflags (fs/super.c:1703) vfsgettree (fs/super.c:1758) pathmount (fs/namespace.c:4131) x64sysmount (fs/namespace.c:4360)(CVE-2026-89785)

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

ext4: fix out-of-bounds read in ext4readinlinedir()

ext4readinlinedir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64():

BUG: KASAN: slab-out-of-bounds in ext4checkdirentry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... ext4checkdirentry ext4readinlinedir iteratedir

The dirent payload lives in a buffer of exactly inlinesize bytes:

dirbuf = kmalloc(inlinesize, GFPNOFS);

but iteration runs in a position space extraoffset bytes larger (extrasize = extraoffset + inlinesize) so the synthetic "." and ".." land at their block-dir offsets. A dirent is formed at "dirbuf + pos - extraoffset", yet the ext4checkdirentry() length argument uses the larger extrasize. A position whose dirent header would extend past extrasize is therefore accepted, and the rescan loop's reclen probe and ext4checkdirentry() dereference de->reclen before the entry is rejected.

Reject a position whose minimum-size dirent header would not fit within extrasize before forming de, in both the rescan and main loops, and pass inlinesize rather than extrasize to ext4checkdirentry() so the length check matches the physical buffer.(CVE-2026-89786)

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

KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save

MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgicitssaveite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVMDEVARMITSSAVETABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths.

Save a zeroed entry, which vgicitsrestoreite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have.(CVE-2026-89912)

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

KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU

When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on.

For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1)

The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmxvcpuloadvmcs() will not request KVMREQTLBFLUSH).

Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing lastvpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmxvcpuloadvmcs().(CVE-2026-89929)

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

mtd: afs: validate v2 image info bounds

The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information regioncount to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use.

Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.(CVE-2026-89954)

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

ALSA: mtpav: shut down output timer before card teardown

sndmtpavoutputtimer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state.

sndmtpavfree() currently takes the same lock and calls timerdelete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer.

A callback running on another CPU can therefore continue after sndmtpavfree() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timerdelete() has returned.

Call timershutdownsync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released.(CVE-2026-90116)

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

NFSv4: remove callback IDR entry on client allocation failure

nfs4allocclient() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfsclient directly with nfsfreeclient(). That bypasses nfsputclient(), which is where the callback IDR entry is removed during normal teardown.

A failed allocation can therefore leave cbidentidr pointing at a freed nfsclient. A later NFSv4.0 callback lookup by cbident would find the stale pointer and take a reference to it.

Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client.

This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.(CVE-2026-90151)

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

ASoC: xilinx: formatterpcm: fix streamdata leak on open error

In xlnxformatterpcmopen(), streamdata is allocated and adata->playstream or adata->capturestream is assigned early. If a later step, such as sndpcmhwconstraintstep() or sndpcmhwconstraintinteger(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so streamdata is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call sndpcmperiodelapsed() on the freed substream.

Free streamdata and clear the stream pointer on the error paths.(CVE-2026-90214)

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

csky: Fix a4/a5 restoration in syscall trace path

The syscall trace path reloads syscall arguments from ptregs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid.

The current code adjusts sp before loading LSAVEA4 and LSAVEA5. Since those offsets are relative to the original ptregs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments.

This is visible with mmap2(), which takes six arguments. A small PTRACESYSCALL reproducer opens a file and maps one page with:

mmap(NULL, 4096, PROTREAD | PROTEXEC, MAPPRIVATE, fd, 0)

Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0.

Fix the trace path by loading a4/a5 from ptregs before changing sp.

Tested on: ck860f, linux-4.19.15, C-SKY abiv2(CVE-2026-93167)

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

wifi: cfg80211: validate assoc response length before status and IE access

cfg80211rxassocresp() initialises the status and response-IE fields of cfg80211connectrespparams from the management frame before proving that the frame is long enough for those offsets. S1G and regular association responses also have different IE offsets, but the S1G path only patched respie after the unsafe initialiser had already run.

Defer respie, respielen, and status to after the link-iteration loop. Use a bool to remember whether the frame is S1G, then validate the appropriate minimum length and set all three fields in a single if/else block. Funnel short-frame and SME-reject cleanup through a shared freebss label for the abandon paths.(CVE-2026-93806)

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

net: stmmac: xgmac2: disable RBUE in default RX interrupt mask

Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring.

However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handlerx - the same outcome as RIE.

On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm.

RBUE does not provide OOM recovery. If pagepool is exhausted, stmmacrxrefill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix.

Note: as a consequence of disabling RBUE, the rxbufunavirq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions.

Remove RBUE from XGMACDMAINTDEFAULTEN and XGMACDMAINTDEFAULTRX to prevent the interrupt storm while keeping normal RX handling intact.(CVE-2026-93830)

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

RDMA/umem: Be careful about boundary conditions in ibumemfindbestpgsz()

Several corner cases, especially important on 32 bits:

- umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK(CVE-2026-97421)

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

genetlink: pin family module during policy dump

The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state. A dump may be split across multiple skbs and remain pending after the initial request.

Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner. The target family can consequently be unregistered and its module unloaded while a policy dump is pending. Advancing the dump then dereferences policy memory from the unloaded module.

Take a reference to the target family's module when the dump starts. Drop it from the error and done paths. This matches the lifetime for which the dump context retains the family and policy pointers.(CVE-2026-97901)

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

smb: client: fix potential OOB read in smb3enumsnapshots()

If snapshotarraysize is smaller than GMTTOKENSIZE, smb3enumsnapshots() sets retdatalen to sizeof(struct smbsnapshotarray) without verifying the actual length of the server's reply.

Because SMB2ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in retdatalen exceeding the size of retbuf. The subsequent copytouser() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces retdatalen.

Fix this by rejecting replies shorter than sizeof(struct smbsnapshotarray) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MINSNAPSHOTARRAYSIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copytouser() attempts to read.(CVE-2026-98169)

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

wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length

mwifiexsearchouiinie() reads a pairwise-cipher (PTK) count from a beacon/probe-response RSN or WPA information element and then walks that many 4-byte OUIs, comparing each with memcmp(). The count comes straight from the (attacker-supplied) IE and is never checked against the element's own length, and the callers admit the element on elementid alone (hasieeehdr() / hasvendorhdr(), no length check). A crafted RSN/WPA IE with a large pairwise count therefore makes the walk read up to 255 4 bytes past the element -- an out-of-bounds read of the kmemdup()'d beacon buffer, reachable from any AP whose beacon/probe response is processed during scan-result parsing.

Pass the number of IE bytes available at the OUI list and bound the walk to the element. Keep the length signed and reject a negative value before any unsigned arithmetic, so a small or zero IE length cannot underflow to a large sizet and defeat the bound.

Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-98186)

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

wifi: brcmsmac: fix UAF in brcmsfreetimer()

brcmsfreetimer() calls brcmsdeltimer() which uses the non-synchronous canceldelayedwork() to cancel the timer's underlying delayed work. If the work callback (brcmstimer) is already running, canceldelayedwork() returns false without waiting, and brcmsfreetimer() proceeds to kfree(t) while the callback still accesses t through containerof().

Add an explicit canceldelayedworksync() after brcmsdeltimer() to guarantee that any in-flight callback has completed before the timer structure is freed.(CVE-2026-98196)

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

xfrm: save input state data before secpath resets

xfrminput() stores the current xfrmstate in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrminput() has finished dereferencing the state.

Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRMMAXDEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol.

If secpathreset() drops the last state reference while the state is concurrently deleted, xfrminput() can still dereference the freed state when selecting transportfinish() or reporting the drop callback protocol.

Save the state protocol on the stack while the state is still valid, and use the already saved address family for transportfinish(). A larval XFRMSTATEACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet.(CVE-2026-98229)

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

swiotlb: use the adjusted address for the highmem page lookup

swiotlbbounce() reads the page frame number from the slot's recorded origaddr, then advances origaddr by tlboffset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it.

Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlboffset, one above for a negative one. DMAFROMDEVICE writes the device data over the wrong page and leaves the intended one stale, DMATODEVICE feeds the device from a page the mapping may not cover. Partial syncs through dmasyncsinglerangefor() are what make tlboffset non-zero.

The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phystovirt().

Take both from origaddr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does.(CVE-2026-98254)

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

exec: Cleanup POSIX timers right after dethread()

A per-thread CPU timer holds a reference to the PID of the thread it is attached to and, while it is armed, its node is queued in that thread's posixcputimers. The task is looked up by that PID.

When a non-leader thread exec()s, dethread() changes which task owns that PID. pidtask(timer->it.cpu.pid, PIDTYPEPID) then returns NULL, but the node is still queued on tsk, which is alive. timerlocksighand() takes a failed lookup to mean that the node is already dequeued, so it has nothing to undo.

beginnewexec() calls posixcputimersexit(me) right after exectasknamespaces() and that removes the leftover node, so the state normally stays invisible. But bprm->pointofnoreturn is set before dethread(), so if unsharefiles(), setmmexefile(), execmmap() or exectasknamespaces() fails, the task dies before it gets there. exititimers() then frees the kitimer while its node is still queued, and reaping tsk later erases that freed node from the rbtree.

In short:

the non-leader thread B the parent

timercreate(CLOCKTHREADCPUTIMEID) timersettime() armtimer() // the node is queued on B execve() dethread(B) exchangetids(B, leader) // B's PID now belongs to the leader releasetask(leader) exitsignal(leader) posixcputimersexit(leader) // cleans leader's queue, not B's unhashprocess(leader) // that PID has no task anymore execmmap() mmapreadlockkillable(oldmm) kill(B, SIGKILL) // -EINTR getsignal() doexit() exititimers() posixtimerdelete() posixcputimerdel() posixtimerunhashandfree() // freed while still queued wait4() releasetask(B) posixcputimersexit(B) cleanuptimerqueue() timerqueuedel() // use-after-free

Move the POSIX timer cleanup right after dethread() before any of the later failure conditions brings the task into doexit().

tglx: Move the cleanup right after dethread()

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

wifi: cfg80211: don't filter by BSS type when removing stale entries

When an assoc AP switches to a channel that already has a BSS entry, cfg80211updateassocbssentry() removes that entry before rehashing the real one, since the two would otherwise collide in the BSS rbtree.

The lookup for that entry also required it to match the connection's BSS type, so an entry advertising e.g. the IBSS capability bit was left in place, and the following cfg80211rehashbss() then ran into it:

WARNON(!cmp)

Changing the type shouldn't really happen, but can be triggered by a rogue AP/device, so drop the check and remove any entries matching the comparison.(CVE-2026-98339)

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

wifi: cfg80211: don't free driver-owned scan requests

When an interface goes down while a scan is running, cfg80211 completes the scan towards userspace and frees the scan request. However, the driver can be convinced that it owns the request, since the cancellation is (intended to be) asynchronous.

The WARNON() in the netdev notifier was meant to catch this, but it's not actually avoidable, so it triggers and we get a UAF in scandone().

There doesn't seem to be a great way around it, so just track that the driver is still convinced it owns the request, and then just free it on completion if it was already cancelled. Also remove the warnings since they can trigger in the intended architecture.(CVE-2026-98341)

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

xfrm: hold netdevice reference under RCU in bundle creation

xfrmbundlecreate() and xfrmcreatedummybundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrmfilldst(). A concurrent RTMDELLINK replaces dst->dev via dstdevput() and frees the old netdevice, causing a use-after-free when xfrm6filldst() later dereferences the stale dev pointer.

BUG: KASAN: slab-use-after-free in xfrm6filldst+0x82c/0x860 (net/ipv6/xfrm6policy.c:86 netdevhold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6filldst+0x82c/0x860 xfrmresolveandcreatebundle+0x21d4/0x2bd0 xfrmlookupwithifid+0x485/0x1640 ip6dstlookupflow+0x19b/0x1e0 udpv6sendmsg+0x1443/0x2dd0

Fix this by reading dst->dev via dstdevrcu() and keeping the RCU read-side critical section active until xfrmfilldst() has taken the required device references.(CVE-2026-98364)

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

xen/netfront: drop RX packets with a short Ethernet header

handleincomingqueue() pulls pullto bytes into the head before calling ethtypetrans(). pullto is the length of the first RX slot, capped at RXCOPYTHRESHOLD, and that length comes from the backend. Nothing checks it against ETHHLEN.

If the first slot is shorter than ETHHLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and ethtypetrans() BUG()s in skbpull(). If the whole packet is shorter than ETHHLEN, ethtypetrans() reads the header past the end of the data instead.

Pull at least ETHHLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored.(CVE-2026-98375)

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

smb: client: use finishnoopen() for non-regular inodes

An OCREAT open can find an existing symlink or another non-regular inode. cifsatomicopen() calls finishopen() on it and attaches a cifsFileInfo. Symlink inodes have no CIFS release operation, so the dentry reference held by cifsFileInfo is leaked. FMODEOPENED also prevents the VFS from following the symlink.

Track whether cifsdocreate() returned an open server handle. For non-regular inodes, close the handle if present, remove the pending open, and call finishnoopen() so the VFS can continue the lookup. Do not set FMODECREATED unless a regular file was opened. For ONOFOLLOW with OREGULAR, return -ELOOP before the VFS's -EFTYPE check.

Defer closing a legacy POSIX handle on a non-regular inode until after inode lookup. This avoids closing it again if lookup fails.(CVE-2026-98451)

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

smb: client: fix create context out-of-bounds reads

smb2parsecontexts() validates the complete create-context area but does not limit each record to its Next field before dispatching it. A malformed chain can therefore expose bytes beyond the current context to a handler. The QFid handler also used a full response-structure cast although it only reads DiskFileId.

The SMB2/SMB3 lease parsers made the same layout assumption: they read LeaseState and LeaseFlags at canonical offsets rather than at DataOffset. A valid non-canonical DataOffset could therefore yield unrelated in-bounds data, while a short DataLength was still accepted.

Limit each context to its Next value, reject offsets before the context header, and reject malformed chains. Bound the name range by the current context and do not dispatch a known handler when DataLength is zero. Read the QFid DiskFileId only when the context data covers that field. Parse the lease context from DataOffset and require DataLength to match the v1 or v2 leasecontext size used by ksmbd. A size mismatch skips lease parsing without failing the open.(CVE-2026-98454)