OESA-2026-3701

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

staging: greybus: uart: fix tty use after free

User space can hold a tty open indefinitely and tty drivers must not release the underlying structures until the last user is gone.

Switch to using the tty-port reference counter to manage the life time of the greybus tty state to avoid use after free after a disconnect.(CVE-2021-47358)

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

net: sched: avoid qdiscresetalltxgt() vs dequeue race for lockless qdiscs

When shrinking the number of real tx queues, netifsetrealnumtxqueues() calls qdiscresetalltx_gt() to flush qdiscs for queues which will no longer be used.

qdiscresetalltxgt() currently serializes qdiscreset() with qdisclock(). However, for lockless qdiscs, the dequeue path is serialized by qdiscrunbegin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with _qdiscrun() and free skbs while they are still being dequeued, leading to UAF.

This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs:

iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done

With KASAN enabled, this leads to reports like:

BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: <TASK> ... __qdisc_run+0x133f/0x1760 __devqueuexmit+0x248f/0x3550 ipfinishoutput2+0xa42/0x2110 ipoutput+0x1a7/0x410 ipsendskb+0x2e6/0x480 udpsendskb+0xb0a/0x1590 udpsendmsg+0x13c9/0x1fc0 ... </TASK>

Allocated by task 1270 on cpu 5 at 44.558414s: ... allocskbwithfrags+0x84/0x7c0 sockallocsendpskb+0x69a/0x830 _ipappenddata+0x1b86/0x48c0 ipmakeskb+0x1e8/0x2b0 udpsendmsg+0x13a6/0x1fc0 ...

Freed by task 1306 on cpu 3 at 44.558445s: ... kmemcachefree+0x117/0x5e0 pfifofastreset+0x14d/0x580 qdiscreset+0x9e/0x5f0 netifsetrealnumtxqueues+0x303/0x840 virtnetsetchannels+0x1bf/0x260 [virtionet] ethnlsetchannels+0x684/0xae0 ethnldefaultsetdoit+0x31a/0x890 ...

Serialize qdiscresetalltxgt() against the lockless dequeue path by taking qdisc->seqlock for TCQFNOLOCK qdiscs, matching the serialization model already used by devresetqueue().

Additionally clear QDISCSTATENON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)

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

seg6: separate dst_cache for input and output paths in seg6 lwtunnel

The seg6 lwtunnel uses a single dstcache per encap route, shared between seg6inputcore() and seg6output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup.

Fix this by splitting the cache into cacheinput and cacheoutput, so each path maintains its own cached dst independently.(CVE-2026-31668)

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

libceph: Fix potential out-of-bounds access in crush_decode()

A message of type CEPHMSGOSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing.

This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crushdestroybucket functions to the generic crushdestroybucket().(CVE-2026-52955)

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

netfilter: nfnetlink_osf: fix out-of-bounds read on option matching

In nfosfmatch(), the nfosfhdrctx structure is initialized once and passed by reference to nfosfmatchone() for each fingerprint checked. During TCP option parsing, nfosfmatch_one() advances the shared ctx->optp pointer.

If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NFOSFLOGLEVELALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nfosfmatchone() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches.

Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nfosfmatch_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.(CVE-2026-52999)

In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr(). ip6t_eui64, xt_mac, the bitmap:ip,mac, hash:ip,mac, and hash:mac ipset types, and nf_log_syslog access eth_hdr(skb) after either assuming that the skb is associated with an Ethernet device or checking only that the ETH_HLEN bytes at skb_mac_header(skb) lie between skb->head and skb->data. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing eth_hdr(skb).(CVE-2026-53131)

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

ip6vti: fix incorrect tunnel matching in vti6tnl_lookup()

In vti6tnllookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels:

• Tunnels matching the packet's local address, with any remote address wildcard remote).

• Tunnels matching the packet's remote address, with any local address (wildcard local).

However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnlsrl) prone to hash collisions.

The bug is that the fallback search loops in vti6tnllookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.(CVE-2026-53221)

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

sctp: fix uninit-value in _sctprcvasconflookup()

_sctprcvasconflookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->fromaddrparam(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length.

An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, fromaddrparam() then reads uninitialized bytes past the parameter.

Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter.

The sibling _sctprcvinitlookup() bounds parameters with sctpwalkparams(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before fromaddrparam() reads it, the same class of fix as commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctpinqpop").(CVE-2026-53225)

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

ipv6: sit: reload inner IPv6 header after GSO offloads

ipip6tunnelxmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnelhandleoffloads().

For GSO skbs, iptunnelhandleoffloads() calls skbheaderunclone(). When the skb header is cloned, skbheaderunclone() can call pskbexpandhead(), which may move the skb head. The pskbexpandhead() contract requires pointers into the skb header to be reloaded after the call.

If the later skbreallocheadroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released.

Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skbreallocheadroom(), since that branch can also replace the skb.(CVE-2026-53228)

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

sctp: don't free the ASCONF's own transport in DEL-IP processing

sctpprocessasconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by _sctprcvasconflookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.

sctpprocessasconfparam() rejects a DEL-IP for the packet source address (ADDIP D8, SCTPERRORDELSRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and calls sctpassocrmpeer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctpassocsetprimary() and sctpassocdelnonprimarypeers(): setprimary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primarypath / activepath, and delnonprimarypeers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transportcount of 0 and primarypath/activepath pointing at freed memory.

Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.(CVE-2026-64564)

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

libceph: refresh auth->authorizer_buf{,_len} after authorizer update

cephxcreateauthorizer() caches au->buf->vec.iovbase and au->buf->vec.iovlen in struct cephauth_handshake. These cached values are then used by the messenger connect code when sending the authorizer.

cephxupdateauthorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, cephxbuildauthorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, cephbufferput() frees the old cephbuffer and its vec.iovbase, but auth->authorizer_buf still points at that freed memory.

A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in copyfromiter() while tcpsendmsg() copies the authorizer.

Refresh auth->authorizerbuf and auth->authorizerbuf_len after a successful authorizer rebuild so the messenger sends the current buffer.(CVE-2026-68156)

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

IB/mad: Drop unmatched RMPP responses before reassembly

Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ibprocessrmpprecvwc() has either assembled a complete message or consumed the segment.

That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send.

For kernel-handled RMPP DATA responses, require the existing ibfindsend_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state.

This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.(CVE-2026-68425)

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

RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path

For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like numsge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxerespchecklength() and copy_data().

Introduce getrecvwqe() that validates numsge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in getsrqwqe(). The srqwqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)