Four aged Linux kernel local root flaws (DirtyAH6, TUNderflow, PPPoEject, DiagSpill) disclosed with PoC exploits; fixes shipped in stable branches

In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.

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.