· via dev.to (home feed)
Four Linux Kernel Local Root Flaws With Public Exploits: DirtyAH6, PPPoEject, TUNderflow, DiagSpill
Four Linux kernel local privilege escalation flaws, all with public proof-of-concept exploits, went public on 18 September 2026. Three need only user-namespace access; one needs no privileges at all.

Four kernel flaws with public exploits
On 18 September 2026, security researcher Asim Manizada published a technical write-up and working proof-of-concept exploits for four Linux kernel vulnerabilities, after a coordinated hold that began when he reported the bugs in mid-July 2026 so distributions could ship fixes first. According to the write-up, relayed in a dev.to post, all four are local privilege escalation bugs: an attacker or malicious process with a foothold on a machine can escalate to root. The four are DirtyAH6 (CVE-2026-80844), PPPoEject (CVE-2026-68121), TUNderflow (CVE-2026-81000) and DiagSpill (CVE-2026-74469).
Upstream, the earliest stable releases that contain all four fixes are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. The 7.0 series reached end of life on 27 June 2026, so a 7.0 kernel only carries the fixes if a vendor backported them.
How each bug works
Three of the four require CAP_NET_ADMIN in a network namespace the attacker controls, which an ordinary local user can obtain by first creating an unprivileged user namespace. DiagSpill is the exception: per the disclosure it requires no special privileges at all.
DirtyAH6 affects the IPv6 Authentication Header code in the IPsec and XFRM path. The code does not check that a routing header's segments_left field is no larger than the number of addresses actually present, so pointer arithmetic in ipv6_rearrange_rthdr() walks out of bounds and an oversized memmove() corrupts kernel memory. It needs AH6 and XFRM support plus CAP_NET_ADMIN and CAP_NET_RAW in a namespace the attacker controls. The researcher also reports a remote crash — and, in his own lab, remote root — against a host acting as an IPv6 router that applies AH in transport mode.
PPPoEject is a use-after-free in pppoe_sendmsg(). The function holds a pointer into the socket buffer head across a dev_hard_header() callback that can reallocate that head, then writes six bytes through the stale pointer. Exploitation needs a lower device whose header callback expands the buffer head, not merely a loadable PPPoE module, which the write-up calls the narrowest of the four in practice.
TUNderflow sits in the TUN/TAP driver, which stores a receive headroom value without bounding it. A device path that propagates oversized headroom — the proof of concept chains a netkit device through Open vSwitch to a raw TUN port — underflows a size calculation and leaves packet data 64 bytes past the end of an allocation. The write-up cautions that simply having a TUN or TAP interface is not sufficient to be affected.
Patch status is uneven
Fixes vary sharply by distribution, according to a status snapshot dated 29 September 2026:
- Debian 13 (trixie): all four first fixed in linux 6.12.111-1, shipped as DSA-6528-1.
- Debian 12 (bookworm): DirtyAH6, PPPoEject and DiagSpill first fixed in linux 6.1.187-1 from bookworm-security. TUNderflow (CVE-2026-81000) remained unfixed on bookworm in that snapshot.
- Ubuntu 22.04, 24.04 and 26.04: the Ubuntu CVE tracker showed no released kernel for any of the four on the main linux packages, with entries at needed or pending.
- Proxmox VE: the Proxmox kernel changelog names only TUNderflow, first fixed in proxmox-kernel-7.0 7.0.14-19 on 18 September 2026, with 7.0.14-20 following on 24 September. The other three CVEs appear nowhere in the changelog, and because the Proxmox 7.0 kernel follows the Ubuntu kernel, the write-up warns against assuming DirtyAH6, PPPoEject and DiagSpill are closed.
- Raspberry Pi OS: no kernel build carrying all four fixes could be confirmed; on the 6.12 branch, 6.12.109 or newer is needed for the full set.
Patching and verifying
The practical steps are straightforward. Record the running kernel with uname -r, apply all available security updates — on Debian and Ubuntu based systems, including Proxmox and Raspberry Pi OS, that means apt update followed by apt full-upgrade — and then reboot, since the kernel in memory remains the old one until restart. After the reboot, confirm the new version string and cross-reference it against the relevant advisory: the Debian security tracker, Ubuntu's security notices, or Raspberry Pi release notes. Because distribution coverage is incomplete, checking per-CVE status matters more than assuming a routine update closed everything.
Why it matters
Local root exploits are often written off as low risk because they require existing access. That framing misses the threat model for homelabs and self-hosted infrastructure. If any exposed service is compromised — a web app, an LXC container with a shared kernel, or a rogue package — a local privilege escalation bug converts that foothold into full node ownership, and public proof-of-concept code for all four lowers the bar considerably. On Proxmox in particular, containers share the host kernel, so a container breakout chained with one of these bugs is a realistic attack path. With Ubuntu and Proxmox still lacking fixes for three of the four at the time of the snapshot, administrators should verify coverage per CVE rather than trust a generic kernel update.
- #linux-kernel
- #security
- #vulnerabilities
- #privilege-escalation
- #sysadmin