CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild

The Linux kernel's in-kernel TLS (kTLS) implementation mishandles zero-length records on the rx_list: each recvmsg() call must process either contiguous DATA records or a single non-DATA record, and the missed corner case occurs when the initial record is pulled from the rx_list and is zero length, breaking the check on record-type changes after zero-copy decryption. A local, low-privileged attacker able to use kTLS sockets can trigger this flaw, and the CVSS vector indicates high confidentiality impact (kernel information disclosure) and high availability impact (crash/DoS), with no integrity impact. Any Linux deployment running a kernel with the TLS (kTLS) feature enabled is affected, including Debian systems, which are listed as affected vendors in CISA's data. CISA added this vulnerability to the Known Exploited Vulnerabilities catalog on 2026-09-18, indicating known exploitation in the wild, though no public proof-of-concept is known and ransomware use is unconfirmed.

Do: Update the Linux kernel to a release containing the upstream fix for this kTLS rx_list issue, applying Debian security updates where applicable, consistent with CISA BOD 26-04 patching guidance. As an interim mitigation, check whether kernel TLS is active (e.g., 'lsmod | grep tls' or CONFIG_TLS in the running kernel) and unload/disable the tls module on hosts that do not require kTLS. Limit local unprivileged access on multi-user systems, since exploitation requires a local low-privileged user.

CVE-2025-39964 is a race condition (CWE-362) in the Linux kernel's AF_ALG crypto socket interface: the af_alg_sendmsg function did not prevent concurrent writes to the same socket, so two simultaneous writes could interleave data unpredictably and leave the kernel's internal socket state inconsistent. It is triggered by a local user (or local process) issuing concurrent write/sendmsg operations on the same AF_ALG socket, which is why the CVSS v3.1 score is low (3.3, local vector, low availability impact). An attacker exploiting the race primarily gains the ability to corrupt socket state, with potential for degraded availability; confidentiality and integrity are not rated as impacted. Any Linux kernel deployment whose build includes the vulnerable af_alg code is affected, though exploitation requires the ability to run local code that uses the crypto socket API. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 2026-09-18, indicating known exploitation in the wild per CISA, but no public proof-of-concept is known and ransomware use is unknown; EPSS estimates a 0.3% probability of exploitation in the next 30 days.

Do: Apply a kernel update from your distribution or vendor that includes the upstream fix 'crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg'; CISA KEV requires mitigating per BOD 26-04 guidance, so prioritize internet-exposed and multi-user systems. Because the vector is local, reduce exposure by limiting untrusted local code execution and auditing hosts that expose crypto-socket workloads; verify the fix by confirming your running kernel includes the af_alg_sendmsg exclusive-ownership patch.

CVE-2026-53266 is an out-of-bounds write (CWE-787) in the Linux kernel's netfilter bridge ebtables SNAT target: when the optional ARP sender-hardware-address rewrite is active, the kernel writes the new MAC address via skb_store_bits() without first making that byte range writable. If the ARP sender hardware address bytes sit in a nonlinear skb fragment backed by a splice-imported file page, the write maps the fragment page and copies the MAC directly into a file-backed page-cache page, corrupting kernel-managed memory. A local, low-privileged attacker (for example a container tenant, VM, or user able to send traffic into a bridge using ebtables SNAT with ARP rewriting) can trigger this with crafted ARP packets, gaining kernel memory corruption usable for privilege escalation or integrity/availability impact (CVSS 3.1 8.8, scope changed). Any Linux system running a kernel with the vulnerable ebtables SNAT code in a bridged-networking configuration that performs this ARP rewrite is affected; the source data does not state specific affected version ranges. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 2026-09-18, indicating known exploitation, although EPSS is low (0.1%, 2nd percentile) and no public proof-of-concept is known.

Do: Update the kernel via your vendor's stable/security channel to a build that includes the upstream fix 'netfilter: bridge: make ebt_snat ARP rewrite writable', prioritizing internet-exposed and multi-tenant hosts in line with CISA BOD 26-04. Audit bridges, routers, gateways and virtualization hosts for ebtables SNAT rules that rewrite ARP sender hardware addresses and remove or disable those rules as an interim mitigation where patching is not yet possible. Restrict untrusted local/guest access to systems using ebtables bridging until patched.

CVE-2026-68121 is a use-after-free in the Linux kernel's PPPoE implementation: pppoe_sendmsg() caches a pointer to the PPPoE header before calling dev_hard_header(), but device header callbacks are allowed to reallocate the socket buffer head, leaving that pointer dangling. The race is triggered when a send blocks in copy_from_user() while the first non-Ethernet port is added to an empty team device, causing the team's delegated GRE header callback to expand the skb head; PPPoE then writes six bytes through the stale pointer into freed memory. A local attacker can leverage this memory corruption for privilege escalation, reportedly reaching a root shell as one of four recently disclosed Linux kernel LPE flaws dubbed 'PPPoEject'. Any Linux system with PPPoE support enabled is potentially affected, though practical exploitation requires local code execution plus the uncommon combination of a PPPoE socket and a team device. A public proof-of-concept has been published on GitHub, but the flaw is not in CISA's KEV catalog and EPSS remains low at 0.1%.

Do: Update to the latest stable or vendor-supplied kernel that includes the upstream fix ('pppoe: reload header pointer after dev_hard_header()') as soon as your distribution backports it. Until patched, restrict local untrusted code execution on PPPoE-connected hosts and avoid combining PPPoE interfaces with team bonding devices or adding non-Ethernet ports to team devices on such hosts. Verify with your kernel vendor whether your running kernel contains the corrected pppoe_sendmsg() and watch distribution security advisories for the backport.

In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.

The Linux kernel's IPv6 Authentication Header implementation (net/ipv6/ah6, part of xfrm) fails to validate the segments_left field of an IPv6 routing header before rearranging addresses for ICV computation, so a crafted raw IPv6 (IP_HDRINCL) packet with hdrlen=2 but segments_left=255 drives pointer arithmetic and a memmove roughly 4,064 bytes out of bounds. A local attacker who can open raw sockets (e.g., holding CAP_NET_RAW, which is commonly granted in containers) can trigger this kernel memory corruption — publicly tracked under the name 'DirtyAH6' — and potentially escalate privileges to root. Any Linux system whose kernel includes IPv6 AH support (the ah6 module) is affected, which spans most mainstream distribution kernels on servers, cloud hosts, containers, and embedded devices. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known; EPSS currently estimates a 0.2% probability of exploitation within 30 days (9th percentile).

Do: Update to a kernel containing the upstream xfrm/ah6 fix once your distribution ships it (no fixed version number appears in the source data, so follow distro advisories for CVE-2026-80844). As interim mitigations, blacklist or avoid loading the ah6 module if you do not use IPsec AH, and remove or restrict CAP_NET_RAW from containers and unprivileged users. Check exposure on hosts with 'lsmod | grep ah6' and audit container runtime capability grants for CAP_NET_RAW.

An integer underflow in the Linux kernel's TUN/TAP driver (net/tun.c) lets tun_get_user() compute a negative linear data size when the configured headroom (tun->align) exceeds the one-page skb-head budget; the value wraps when stored as a size_t, so tun_alloc_skb() can place skb->data outside the allocated buffer. The oversized headroom can be set locally or propagated to a TUN/TAP port by Open vSwitch when packets arrive from another port, so triggering requires injecting packets into a TUN/TAP device with a large alignment value, which needs local access with privileges. Successful exploitation corrupts kernel memory adjacent to the skb, giving a local attacker full confidentiality, integrity, and availability impact (CVSS 7.8), i.e., potential ring-0 code execution and complete host compromise. Any system running a kernel with the vulnerable tun_get_user() logic is affected, with VPN gateways, container hosts, and Open vSwitch/SDN deployments the most likely exposure paths. No public PoC is known, the flaw is not in CISA's KEV, and no exploitation in the wild has been reported.

Do: Apply a kernel update containing the upstream fix commit "net: tun: bound receive headroom" as soon as your distribution or vendor backports it. In the interim, restrict access to /dev/net/tun and CAP_NET_ADMIN for untrusted local users and containers, and review Open vSwitch bridges that forward traffic from ports with large headroom requirements into TUN/TAP ports. Monitor kernel logs for OOPS or BUG output in the tun_get_user/tun_alloc_skb paths as a sign of attempted abuse.