OESA-2026-4810: kernel security update

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

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

wifi: brcmsmac: Fix dmafreecoherent() size

dmaallocconsistent() may change the size to align it. The new size is saved in alloced.

Change the free size to match the allocation size.(CVE-2026-31661)

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

drm/amd/display: Validate GPIO pin LUT table size before iterating

[Why&How] The GPIO pin table parsers in getgpioi2cinfo() and biosparsergetgpiopininfo() derive an element count from the VBIOS tableheader.structuresize field, then iterate over gpiopin[] entries. However, GETIMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read.

Fix this by calling biosgetimage() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions.

(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)

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

usbip: vudc: fix NULL deref in vepdequeue()

vepallocrequest() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vepdequeue without a valid UDC reference.

Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vepdequeue to obtain a reference to the udc with eptovudc(), consistent with the other vep ops.

AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc.

I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running usbip attach from the host would cause the guest to oops with the following backtrace:

Call trace: vepdequeue+0x1c/0xe4 (P) usbepdequeue+0x14/0x20 ffsaiocancel+0x24/0x34 arm64sysiocancel+0xb0/0x124 doel0svc+0x68/0x100 el0svc+0x18/0x5c el0t64synchandler+0x98/0xdc el0t64sync+0x154/0x158(CVE-2026-64331)

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

Bluetooth: bnep: pin L2CAP connection during netdev registration

bnepaddconnection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to registernetdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device.

Take a reference to the L2CAP connection while holding the channel lock. Retain it until registernetdev() has taken the parent device reference.(CVE-2026-64408)

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

drm/amd/display: set newstream to NULL after release

In dmupdatecrtcstate(), the skipmodeset path releases newstream via dcstreamrelease() but does not set the pointer to NULL.

If a later error (e.g., color management failure) triggers the fail label, the error path calls dcstreamrelease() again on the same dangling pointer, causing a double release and potential use-after-free.

Fix this by setting newstream to NULL after the initial release.

(cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)(CVE-2026-68236)

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

ipv6: fix Route Information option length validation

rt6routercv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one.

rinfo->length is the ND option length in units of 8 octets and it includes the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively.

ipv6addrprefix() then copies prefixlen/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefixlen=128, length=2) or (prefixlen=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace:

# RA with a Route Information option (prefixlen=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds

When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead.

Reject the option lengths RFC 4191 does not allow.(CVE-2026-74598)

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

net: cap advertised IP tunnel headroom

IP tunnel devices derive their advertised neededheadroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets.

The runtime transmit path already caps a growing neededheadroom at 512. Apply the same cap when tunnel configuration publishes neededheadroom derived from a lower output device.

Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.(CVE-2026-80978)

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

net: kcm: Hold RCU read lock while running BPF parser

kcmparsefuncstrparser() calls bpfprogrunpinoncpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARNONONCE(!bpfrculockheld()) when called from the KCM strparser program.

Hold the RCU read lock while running the program.(CVE-2026-90143)

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

NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers

flexfiles accepts NFSv4.0 data servers, but two NFSv4 code paths assume the data server client has a session. Unlike NFSv4.1+, an NFSv4.0 client has no session (clp->clsession is NULL; it uses clp->clslottbl), so I/O to a v4.0 flexfiles DS oopses:

- nfs4initdssession() dereferences clp->clsession->sessionstate while seeding the DS lease. It also only seeds clleasetime when NFS4SESSIONINITING is set; without a session that never happens, so clleasetime stays 0 and nfs4renewstate() busy-loops, requeuing every 5 seconds. Seed the lease whenever there is no session and return before touching session state.

- fflayoutasynchandleerrorv4() dereferences clp->clsession->fcslottable on every DS I/O error. Fall back to the v4.0 transport slot table (clp->clslottbl) when there is no session.(CVE-2026-90149)

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

RDMA/siw: Fix use-after-free in siwaccept()

siwaccept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it.

The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association.

Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.(CVE-2026-90292)

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

uio: Fix stale info pointer in failed registration path

After deviceadd(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, uioregisterdevice() unwinds the device but leaves idev->info pointing at the caller-owned struct uioinfo.

That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uiodevice, while the caller sees registration failure and may free its struct uioinfo. Later file operations can then follow idev->info and dereference freed memory.

Handle post-deviceadd() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under infolock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same "device gone" state as normal uiounregisterdevice().(CVE-2026-93054)

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

wifi: iwlwifi: pcie: null RX pointers after free

When iwlpcietxinit() fails after RX init, nic init unwinds via iwlpcierxfree().

The freed RX members stayed non-NULL on the live transport object, so later teardown or retry could touch stale RX state. Set rxpool, globaltable, rxq, and allocpage to NULL after free to make repeated cleanup and retry paths safe.(CVE-2026-93796)

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

wifi: virtwifi: don't transfer operstate before register

virtwifinewlink() calls netifstackedtransferoperstate() before registernetdevice(). If the lower device is dormant, that queues the new netdev on lweventlist while it is still uninitialized. If registration fails after that, for example because of an invalid name such as "bad/name", freenetdev() immediately frees the object. A later linkwatchfireevent() then use-after-frees the list entry.

Move the transfer to after netdevupperdevlink(), as macvlan and ipvlan already do.(CVE-2026-98311)

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

ALSA: pcm: set timer->privatedata before registering the PCM timer

sndpcmtimerinit() calls snddeviceregister() to link the new struct sndtimer into the global timer list while it still carries hw.cresolution = sndpcmtimerresolution (and hw.start/hw.stop), and only afterwards sets timer->privatedata = substream.

Once the timer is on the list under registermutex, a concurrent reader can already reach it through the same mutex and invoke these callbacks. /proc/asound/timers does this via cresolution(), and sndtimeropen()+sndtimerstart() reach start()/stop() the same way. All three dereference timer->privatedata, which for this brief window is NULL, giving a NULL-pointer dereference:

substream = timer->privatedata; return substream->runtime ? ... // substream is NULL

Move the privatedata/privatefree assignment before snddeviceregister() so the timer is never visible on the list without its privatedata set. On the snddeviceregister() failure path, privatefree() (sndpcmtimerfree()) can now run, but it only does substream->timer = NULL, which is already NULL at that point since substream->timer is set to the new timer just once, after a successful registration -- so the failure path stays safe.(CVE-2026-98314)

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

wifi: mac80211: unlist vifs when their netdev is unregistered

mac80211 only removes vifs from the local->interfaces list when an interface is removed via ieee80211ifremove(), before it unregisters the netdev. However, it's possible for a netdev to be unregistered without going through that: When the netns that holds the wiphy is destroyed, the wiphy is supposed to move to the initns, but that can run into allocation failures.

Then, mac80211 has an interface listed that doesn't exist, and will eventually hit

BUG: failure at net/wireless/core.h:141/wiphytordev()! ... cfg80211unregisterwdev+0x24/0x36a [cfg80211] cfg80211unregisterwdev+0x15/0x1d [cfg80211] ieee80211removeinterfaces+0x1ff/0x257 [mac80211] ieee80211unregisterhw+0x73/0x1d1 [mac80211] mac80211hwsimdelradio+0x114/0x166 [mac80211hwsim]

Remove the interface from the list in ->ndouninit if it's still around to avoid this.(CVE-2026-98331)

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

dmaengine: fix use-after-free in dmachanput() and dmareleasechannel()

When dmadeviceput() drops the last reference on chan->device->ref, dmadevicerelease() runs and may free the dmadevice along with its channels.

dmachanput() then still reads chan->device->owner via dmachantoowner() for the trailing moduleput(). KASAN catches it:

slab-use-after-free in dmachanput+0x3e6/0x4c0 Read of size 8 by task insmod/6319 Freed by task 6319: kfree+0x225/0x470 dmachanput+0x395/0x4c0 dmaengineput+0xf8/0x160

Cache the module owner in dmachanput() before the put so the trailing moduleput() does not need chan->device.(CVE-2026-98343)

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

clk: scpi: bound-check DVFS index in scpidvfsrecalcrate

dvfsgetidx() may return an out-of-range index if the SCP firmware is buggy or returns a stale value. Only negative indexes were rejected, so a large index walked past info->opps and could treat garbage as a clock rate (KASAN OOB / wrong frequency to consumers). The missing upper bound dates back to the original SCPI clock driver.

Treat indexes >= opp count as invalid and return 0, same as idx < 0.(CVE-2026-98362)

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

vlan: require the MAC header to be present in vlaninsertinnertag()

vlaninsertinnertag() only guarantees head room via skbcowhead(), never that maclen bytes of MAC header are present. Its ETHHLEN wrappers - vlaninserttag() under skbvlanpush(), and vlaninserttag() under validatexmitvlan() on the generic transmit path - therefore rewrite the first 16 bytes at skb->data: a 12-byte memmove plus two 2-byte stores at +12 and +14. No caller supplies the bound, while the pop helpers use skbensurewritable()/pskbmaypull().

An IFFTUN device has hardheaderlen == 0, so packetsnd() accepts a one-byte AFPACKET/SOCKRAW frame. The first vlan push only sets a hwaccel tag; the next - clsact "action vlan push" or bpfskbvlanpush() - enters the helper with skb->len still 1. The head comes from skbuffsmallhead without GFPZERO, so each push drags bytes from beyond skb->tail into the frame. After three the one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised slab:

0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81 ------------------------------' only 0x5a was sent; the rest is slab, here the top 56 bits of a linear-map address

Require the MAC header the helper rewrites to be present, so such a frame is dropped rather than transmitted.(CVE-2026-98377)

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

wifi: rsi: fix heap OOB write on key removal

When a key is removed (data == NULL), rsihalloadkey() runs:

memset(&setkey[FRAMEDESCSZ], 0, framelen - FRAMEDESCSZ);

setkey is a struct rsisetkey , so the subscript is scaled by sizeof(struct rsisetkey) (160 bytes): &setkey[FRAMEDESCSZ] is skb->data + 2560, and the memset writes 144 zero bytes starting 2.4KB past the end of the 160-byte skb data buffer, corrupting unrelated heap objects. The intended byte offset would have been (u8 )setkey + FRAMEDESCSZ.

The write fires on every DISABLEKEY callback, so plain disconnects, roams and interface teardowns trigger it on real networks.

The memset is redundant: the whole buffer is zeroed right after allocation, so the frame sent to the device is byte-identical without it. Drop the else branch; normal operation is unaffected.

Discovered by Atuin - Automated Vulnerability Discovery Engine.(CVE-2026-98407)

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

dmaengine: ti: k3-udma-glue: fix NULL dereference in k3udmagluereleaserxchn()

If devmkcalloc() for rxchn->flows fails in a channel request function, the error path calls k3udmagluereleaserxchn(), which dereferences the NULL rxchn->flows pointer in k3udmagluereleaserxflow().

Skip the flow release loop in k3udmagluereleaserxchn() when rxchn->flows is not allocated.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-98416)

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

net: xfrm: reject unrepresentable espintcp transport headers

ESP-in-TCP can hand xfrm packets whose transport header offset no longer fits after the stream parser trims the TCP envelope. The plain transport header reset truncates that offset and triggers the skb warning path.

Use the careful transport-header helper and drop the skb through the existing XFRM error path when the offset cannot be represented.(CVE-2026-98417)

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

wifi: mac80211: reset the APVLAN tailroom counter on ifdown

On ifup, APVLAN interfaces get cryptotxtailroomneededcnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same APVLAN up again will increment the counter again and eventually hit the sanity check:

WARNONONCE(sdata->cryptotxtailroomneededcnt != master->cryptotxtailroomneededcnt);

Reset it on ifdown to avoid that.(CVE-2026-98422)

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

ipv4: free inetopt and ireqopt after an RCU grace period

tcpv4synrecvsock() transfers ownership of ireq->ireqopt to the child socket (newinet->inetopt) without copying it.

Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcpcheckreq(). tcpv4sendsynack() and inetcskroutereq() read ireq->ireqopt under rcureadlock() only, and ipbuildandsendpkt() and ipoptionsbuild() then read opt->optlen twice.

Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inetcskreqskqueuedrop() calls timerdeletesync() before the child can be freed.

Since commit 079096f103fa ("tcp/dccp: install synrecv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCKRCUFREE, and inetsockdestruct() frees inetopt with a plain kfree(), leading to a use-after-free in ipoptionsbuild().

A similar issue exists with request socket migration (net.ipv4.tcpmigratereq=1, or a BPFSKREUSEPORTSELECTORMIGRATE program). reqsktimerhandler() clones the request socket with inetreqskclone(), so that the old request socket and its clone share the same ireqopt, then reqskmigratereset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcpv4synrecvsock()) when the clone is freed, and tcpv4reqskdestructor() also uses a plain kfree().

Readers already use RCU, and other paths replacing inetopt (doipsetsockopt(), cipsov4socksetattr()...) already use kfreercu(). Use kfreercu() in inetsockdestruct() and tcpv4reqskdestructor() as well.

IPv6 is not affected by the first issue, because tcpv6synrecvsock() duplicates the options. tcpv6reqskdestructor() has the same migration issue with ipv6opt, which is only set by CALIPSO. This will be addressed in a separate patch.(CVE-2026-98432)

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

net: openvswitch: conntrack: fix helper UAF due to extensions realloc

While calling the helpers, a raw pointer to the extensions area is wired into expectations list:

-> nfcthelper() -> helper->help() -> nfctexpectrelatedreport() -> nfctexpectinsert() -> hlistaddheadrcu(&exp->lnode, &masterhelp->expectations)

In case the connection is not confirmed yet, more extensions can be added afterwards with extadd() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the expectation.

Make sure that helpers are called at the end after all the other extensions are already added.

Note that the helper rejection now leaves the mark and labels set, but that's not different from how the NAT was handled before or how the mark and the labels were handled on confirmation failure. And there are no atomicity guarantees provided by the API anyway.(CVE-2026-98490)

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

netfilter: flowtable: publish HWDEAD after worker is done

flowoffloadworkdel() sets NFFLOWHWDEAD before the work handler clears NFFLOWHWPENDING. Once a flow is both HWDYING and HWDEAD, a concurrent garbage collection pass can remove it and schedule it for RCU freeing.

The offload worker holds neither an RCU read lock nor a reference to the flow. If it is preempted after publishing HWDEAD, the RCU callback can free the flow before the worker resumes and clears HWPENDING, resulting in a use-after-free.

Move HWDEAD publication to the common worker epilogue after the pending bit is cleared, making it the final flow access by destroy work. Order all preceding flow accesses before publishing the bit that allows garbage collection to free the object.(CVE-2026-98625)

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

netfilter: ipset: mark the rcu locked areas properly

When we bump the uref counter, there's no need to keep the rcu lock because the referred hash table can't disappear. Also, from the same reason in mtypegc we need the rcu lock and not a spinlock.(CVE-2026-98899)

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

wifi: ath11k: reset ar->numstations on hardware start

When (multiple) hw restart occurs, we end up in a situation where we cannot accept new stations / mesh peers. This seems to be the 'numstations' in 'struct ath11k' that did not get reset properly in this case. In ath11kmacopstart(), it was indeed the only accounting var that did not get reset so let's clear it too.

This avoids problems like those:

[1248828.088023] WARNING: CPU: 0 PID: 12281 at net/mac80211/util.c:1682 ieee80211reconfigstations+0x98/0xc0 [1248828.088115] Call trace: [1248828.088116] ieee80211reconfigstations+0x98/0xc0 (P) [1248828.088119] ieee80211reconfig+0x774/0x1438 [1248828.088123] ieee80211restartwork+0x10c/0x178 [1248828.088127] processonework+0x178/0x3c0 [1248828.088130] workerthread+0x280/0x440 [1248828.088133] kthread+0xe0/0xf8 [1248828.088137] retfromfork+0x10/0x20 [1248828.088141] ---[ end trace 0000000000000000 ]--- [1248836.686604] ath11kpci 0000:04:00.0: refusing to associate station: too many connected already (128) [1248836.686609] ath11kpci 0000:04:00.0: Failed to add station: xx:xx:xx:xx:xx:xx for VDEV: 1

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPLSILICONZ-1(CVE-2026-98936)

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

wireguard: noise: reject response consumption after intermediate initiation

Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on downwrite(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same downwrite(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls upwrite(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire downwrite(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A.

Thread A Thread B Thread C

downread() sA = handshake->state memcpy(cA, handshake->crypto) upread() if (sA != 1) goto fail slowcrypto(cA) downread() sB = handshake->state memcpy(cB, handshake->crypto) upread() if (sB != 1) goto fail slowcrypto(cB) downwrite() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 upwrite() downwrite() if (handshake->state != 2) goto fail derivesession(handshake->crypto) upwrite() downwrite() slowcrypto(handshake->crypto) handshake->state = 1 upwrite() downwrite() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 upwrite() downwrite() if (handshake->state != 2) goto fail derivesession(handshake->crypto) upwrite()

This seems basically impossible to hit in a meaningful way in practice, but ensure that it absolutely cannot happen by comparing the ephemeral private key that's on the stack with the latest one that the peer's handshake state has.(CVE-2026-99059)

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

ipv4: udp: Create exceptions before socket matching

Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket.

This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket.

Commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhehashfun()") and commit 67d6d681e15b ("ipv4: make exception cache less predictible") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed.

Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4updatepmtu() and ipv4redirect(), the helpers used when the quoted packet did not originate from a socket.

This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe.

Pass an oif of 0, in a similar fashion to icmperr(). This is also the oif used by the socket path for sockets that are not bound to a device.

Note that this does not allow attackers to create FNHEs that they could not create before, as both helpers can already be reached with little to no validation. For example, by sending an ICMP error that quotes an ICMP Echo Reply or one that quotes a UDP source port that matches a wildcard socket.

Also note that in the good case (matched socket) the above scheme comes at the cost of an extra route lookup, as the no socket helpers perform their own lookup before the one performed by ipv4skupdatepmtu() / ipv4skredirect(). When the two resolve to different nexthops, it also results in two exceptions being created for the same destination IP. One in the FNHE cache of the nexthop resolved by the no socket helpers and another in the FNHE cache of the nexthop used by the socket.(CVE-2026-99077)

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

net: bridge: mcast: don't truncate the port group walk on teardown

brmulticastdisableportctx() and brmulticastdelport() walk port->mglist with hlistforeachentrysafe(). However, brmulticastfinddelpg() can also delete other entries from the same list through brmulticastfwdsrcremove() or fwddelstarexcl().

If such an entry is the iterator's saved next node, hlistdelinit() clears its ->next and terminates the walk early. The reproducer triggers this in both teardown walks, leaving port groups in the bridge mdb with a dangling ->key.port after delnbp() frees the port:

BUG: KASAN: slab-use-after-free in mdbfillinfo+0x1191/0x1320 mdbfillinfo+0x1191/0x1320 brmdbdump+0x594/0xe40 rtnlmdbdump+0x1cf/0x5d0

Use hlistdelinitrcu() to unlink the group while preserving ->next. brmulticastdelpg() and the teardown walks run under br->multicastlock. The GC worker must acquire the same lock before detaching the group for destruction, so the node remains alive while the walk uses the preserved pointer.

Preserving ->next means a walk can now reach a group that an earlier iteration already deleted as a side effect. That group is off mp->ports, so brmulticastfinddelpg() would fall through its port scan and hit the trailing WARNON(1). Skip such groups at the top of that helper: a port group is put on port->mglist when it is created and only unlinked when it is deleted, so hlistunhashed() identifies exactly this case.(CVE-2026-99117)

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

tracing: Check operator stack capacity before pushing

predicateparse() uses the first operator stack entry before processing any opening parentheses. A push then increments top before writing. The existing check still permits that write when top already points to the last allocated entry, which can access beyond the operator stack.

Reject the push when top reaches the last allocated entry.(CVE-2026-99142)

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

net/sched: fix use-after-free in tcfactionput()

tcfactionput() decrements the reference count before decrementing the binding count. Another thread can free the action between these operations, causing the binding-count update to access freed memory. KASAN reports it as:

BUG: KASAN: slab-use-after-free in tcfactionput+0x327/0x340 Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64

Hold the action IDR mutex across both counter updates and IDR removal, keeping cleanup outside the lock.(CVE-2026-99167)

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

tracing/histograms: Verify eventcall identity when updating synthevent refcount

In eventhisttriggerparse() and histunregall(), the histogram registration and unregistration paths look up findsynthevent() using traceeventname(file->eventcall) and adjust se->ref if a match is found.

Because findsynthevent() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it.

Introduce findsyntheventcall() to verify that &se->call matches file->eventcall before adjusting se->ref.(CVE-2026-99233)

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

tracing: Save the event file instead of the compatible histogram

createfieldvarhist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later:

histdata = findcompatiblehist(targethistdata, file); ... / Save the compatible histogram information / varhist->histdata = histdata;

histdata is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregisterfieldvarhists(), which runs when the target is removed:

file = histdata->fieldvarhists[i]->histdata->eventfile;

findcompatiblehist() matches on keys alone, so it can pick one with no variables of its own. checkvarrefs() then returns false and the user can remove it while the target still points at it:

BUG: KASAN: slab-use-after-free in eventhisttriggerfree+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1

Freed by task 1: kfree+0x154/0x420 eventhisttriggerfree+0x1d5/0x320 eventhisttriggerparse+0x35f3/0x69e0 triggerprocessregex+0x1a6/0x250

Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger.(CVE-2026-99235)

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

tracing: Reject incomplete event filter expressions

A non-empty expression normally finishes in predicateparse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state.

For example, "commonpid == 1 || commonpid == 2 &&" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERFEVENTIOCSETFILTER.

Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations.(CVE-2026-99236)

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

Bluetooth: L2CAP: refuse l2capchanadd if chan already has conn

l2capchan may be linked to l2capconn at most once. This is assumed in several places, eg l2capchandel cleanup.

There is a TOCTOU race where the invariant is violated:

[Task 1] [Task 2] l2capchanconnect l2capsockbind l2capchanlock locksock l2capstatechange if (sk->skstate != BTOPEN) chan->state = BTCONNECT l2capsockstatechangecb chan->state = BTBOUND sk->skstate = BTBOUND locksock <------------------ releasesock sk->skstate = BTCONNECT

l2capsockconnect() does not check sk->skstate, so since chan->state is now BTBOUND, subsequent connect() ends up with second l2capchanadd.

Explicitly document and check the invariant in l2capchanadd with WARNONONCE. The only callsite where it could be hit is l2capchanconnect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems.

Add l2caplockchan in l2capsockbind() to guard chan->state write.(CVE-2026-99239)