Public Exploits Released for Four Linux Kernel Flaws That Enable Local Root Access

A security researcher has released working exploit code for four Linux kernel vulnerabilities that allow local users to gain root access. All four flaws have been patched, but unpatched systems remain at serious risk — and with exploit code now publicly available, the window for attackers to act is open.

Security researcher Asim Manizada disclosed four critical Linux kernel vulnerabilities on September 18, 2026, publishing working exploit code after a coordinated hold with Linux distributions. The flaws — dubbed DirtyAH6, TUNderflow, PPPoEject, and DiagSpill — affect the kernel's networking subsystems and represent some of the most significant local privilege escalation vulnerabilities disclosed this year. System administrators running older kernels face an urgent remediation priority.

---

What the Four Flaws Are and How They Work

Manizada reported all four vulnerabilities to the Linux kernel security team in mid-July 2026. Each flaw is rooted in memory-safety errors within different sections of the kernel's networking code. Notably, the underlying coding mistakes range from 10 to 21 years old — a sobering reminder that legacy code buried deep in critical infrastructure can harbor dangers for decades. For organisations that haven't formalised how they identify and respond to weaknesses like these, building a structured vulnerability management process is an essential foundation.

DirtyAH6 (CVE-2026-80844)

DirtyAH6 lives in the IPsec code handling the IPv6 Authentication Header. The code trusted a routing-header field without verifying it against the number of addresses present. A crafted packet could push an internal pointer far out of bounds and write past the buffer — a classic out-of-bounds write enabling privilege escalation.

TUNderflow (CVE-2026-81000)

TUNderflow affects TUN and TAP virtual network devices. A single value was used both as spare space and as a size. An oversized value passed through Open vSwitch caused the size calculation to wrap around, landing packet data outside its designated buffer. This integer overflow–style mistake is deceptively simple but exploitable in practice.

PPPoEject (CVE-2026-68121)

PPPoEject is found in the PPP over Ethernet code. The flaw kept a pointer into a network buffer while calling a device routine that could free and relocate that buffer. Subsequent writes then used freed memory — a classic use-after-free vulnerability that has long been a favourite target for privilege escalation.

DiagSpill (CVE-2026-74469)

DiagSpill sits in the SCTP diagnostics reporting code. A 16-bit counter tracking connection endpoints wraps back to zero at 65,536 entries. The reporting code then allocates no space but copies the full list, writing roughly 8 megabytes of data past the end of its buffer. The sheer volume of out-of-bounds data written makes this flaw particularly destructive in terms of memory corruption.

---

Who Is at Risk and What Makes DiagSpill Stand Out

Three of the four flaws — DirtyAH6, TUNderflow, and PPPoEject — require unprivileged user namespaces to be enabled, a Linux feature that allows a normal user to act as root inside a private sandbox. Many distributions enable this by default, creating a readily available path for a low-privileged attacker on a multi-user server to escalate to full control.

DiagSpill is the exception and arguably the more dangerous outlier. It requires no user namespaces or special privileges at all — only that the SCTP networking module is available on the system. This zero-prerequisite exploitation path makes it the most broadly accessible of the four flaws.

Network Exposure and Container Risk

Manizada confirmed that DirtyAH6 and DiagSpill can be triggered over a network, though only in narrow conditions and primarily to crash a system rather than achieve remote root. He noted that reaching remote root with DirtyAH6 "looks extremely difficult" outside of a controlled lab environment. For DiagSpill, he stated he sees no path to remote root even under ideal conditions.

He also acknowledged the flaws could theoretically enable container escapes, but did not build a working proof of concept for that scenario. Organisations running containerised workloads should treat this as an unresolved risk worthy of close monitoring. A thorough vulnerability assessment of exposed systems and container environments is a practical step to understand where exposure exists before an incident occurs.

So far, there are no confirmed reports of any of the four vulnerabilities being exploited in real-world attacks.

---

How the Flaws Were Found and What to Do Now

AI-Assisted Discovery and a Notable First

In a detail that underscores a growing trend in vulnerability research, Manizada said he discovered all four flaws using an AI-assisted process that builds a map of kernel memory handling and reasons about its layout. The kernel's fix commit for DirtyAH6 even includes an "Assisted-by" line crediting his custom AI tooling — a notable first for Linux kernel patch documentation.

This follows his disclosure of a similar Open vSwitch flaw called OVSwrap in July 2026 and builds on techniques from Dirty Frag, another Linux kernel root vulnerability disclosed in May by a separate researcher. The trend is clear: AI tooling is accelerating the pace at which deep kernel vulnerabilities are surfaced. Security teams should assume that rate will only increase.

Patch Versions and Immediate Remediation

System administrators should update to a kernel version that carries all four fixes. The first stable releases with the complete patch set are:

• 5.10.270
• 5.15.221
• 6.1.188
• 6.6.157
• 6.12.109
• 6.18.50
• 7.2.4, and beyond

Because most production systems run distribution-specific kernels from vendors such as Debian, Ubuntu, Red Hat, or SUSE, administrators should consult their distribution's security advisory rather than matching version numbers directly. The official Linux kernel website provides release notes and security-relevant changelogs for reference.

Interim Mitigations for Systems That Cannot Be Patched

For systems that cannot be patched immediately, two interim steps reduce exposure:

• Disabling unprivileged user namespaces closes the ordinary-user path to DirtyAH6, TUNderflow, and PPPoEject — though it does not address DiagSpill.
• Disabling unused features including AH6, TUN/TAP, PPPoE, and SCTP limits the attack surface where those components are not operationally required.

Manizada himself recommends patching over feature removal, warning that other paths to the same flaws may exist. Interim mitigations are a holding position, not a resolution.

Prioritising Remediation Across Multi-User and Cloud Environments

The release of working public exploit code transforms these vulnerabilities from theoretical risks into active threats for any unpatched system. Administrators managing shared servers, cloud infrastructure, or multi-user environments should treat this as a priority remediation event. Verifying kernel versions against distribution advisories and auditing whether unprivileged user namespaces are enabled are immediate steps any security team can take today.

For teams looking to go beyond reactive patching and build a repeatable process for identifying and handling flaws of this nature, understanding how penetration testing can surface privilege escalation risks before attackers do is a meaningful investment. Organisations running container workloads should also review their exposure given the unconfirmed but credible container escape vector Manizada identified.