Public Exploits Released For Multiple Linux Kernel Flaws Enabling Root Access

The vulnerabilities—some of which remained undetected for more than two decades—affect several Linux networking components and could potentially be used to escape containers or, under narrowly defined conditions, attack systems remotely.

Security teams are being urged to accelerate Linux kernel patching after working proof-of-concept exploits were published for four memory-corruption vulnerabilities capable of elevating an ordinary local user to root.

The vulnerabilities, named DirtyAH6, TUNderflow, PPPoEject and DiagSpill , affect separate parts of the Linux kernel’s networking stack. Each can be exploited to corrupt kernel memory and ultimately execute code with the operating system’s highest privileges on a suitably configured and vulnerable machine.

The four flaws are tracked as:

CVE-2026-80844 , known as DirtyAH6 CVE-2026-81000 , known as TUNderflow CVE-2026-68121 , known as PPPoEject CVE-2026-74469 , known as DiagSpill

CVE-2026-80844 , known as DirtyAH6

CVE-2026-81000 , known as TUNderflow

CVE-2026-68121 , known as PPPoEject

CVE-2026-74469 , known as DiagSpill

Linux kernel maintainers have already addressed all four vulnerabilities, and fixes have been incorporated into multiple supported stable kernel branches. However, the release of functional exploit code significantly increases the risk for organizations that have not yet installed the updates and rebooted affected systems.

The vulnerabilities were discovered by security researcher Asim Viladi Oglu Manizada , who reported them privately to the Linux kernel security team and the relevant maintainers in mid-July 2026. Details and proof-of-concept code were released on September 18 following a coordinated disclosure process involving the linux-distros security mailing list.

According to Manizada’s technical analysis of the four vulnerabilities , the underlying programming errors had existed in the Linux kernel for between 10 and 21 years. Although the affected components are associated with networking technologies that may not be actively used on every Linux system, the corresponding kernel functionality is commonly available in general-purpose Linux distributions.

The publication changes the threat picture because attackers no longer need to independently develop complete exploitation techniques. While the released exploits are tailored to particular operating systems, kernels and hardware configurations, they provide a working technical foundation that could be adapted to additional environments.

Local Access Can Become Complete System Control

These are primarily local privilege-escalation vulnerabilities. An attacker generally needs some initial ability to run code on the targeted machine before attempting to exploit them.

That requirement does not make the vulnerabilities low risk. Threat actors frequently obtain limited access through stolen credentials, vulnerable web applications, exposed development services, malicious packages, compromised containers or other remote-code-execution vulnerabilities. A local kernel exploit can then provide the second stage needed to turn that restricted foothold into full control of the host.

Root access would allow an attacker to disable security products, access credentials, extract protected information, modify system files, establish persistent backdoors and interfere with logging. On shared or virtualized infrastructure, successful exploitation could also threaten workloads belonging to other users.

Manizada said all four published proofs of concept demonstrate a path from an unprivileged local account to root-level code execution on their intended targets. However, because they exploit memory corruption, their reliability can depend on the precise kernel build, processor architecture, memory layout and other characteristics of the target.

The researcher warned that the released programs deliberately corrupt live kernel memory and should only be run on disposable virtual machines or controlled test systems. An unsuccessful attempt could crash the operating system or damage unrelated kernel data.

DirtyAH6: IPv6 Authentication Header Validation Failure

DirtyAH6, tracked as CVE-2026-80844 , affects the Linux implementation of the IPv6 Authentication Header and the kernel’s IPsec-related XFRM framework.

The Authentication Header is intended to protect the integrity of IP traffic by enabling a recipient to verify that selected parts of a packet were not modified in transit. Before Linux calculates or verifies the authentication data, the kernel normalizes certain IPv6 fields, including information contained in routing headers.

The vulnerability originated in the ipv6_rearrange_rthdr() function. The vulnerable code calculated the number of addresses represented by the header but failed to confirm that the packet’s segments_left value was within the expected range before using it in pointer arithmetic.

A specially constructed IPv6 packet could therefore move a pointer backwards beyond the legitimate buffer and cause the kernel to perform an out-of-bounds memory operation. Manizada demonstrated that the condition could be converted into a local root exploit by corrupting kernel networking structures and manipulating a subsequent operation involving file-backed memory.

The normal local exploitation route requires AH6 and XFRM functionality together with unprivileged user and network namespaces. An alternative route is possible where a process already holds CAP_NET_ADMIN and CAP_NET_RAW inside an attacker-controlled network namespace.

DirtyAH6 also has a narrowly defined remote dimension. A Linux machine acting as an IPv6 router or gateway and applying Authentication Headers in transport mode could reportedly be crashed remotely.

Manizada achieved remote root access in a laboratory environment when memory grooming could also be performed locally on the target. He assessed a fully remote root attack as theoretically possible but extremely difficult, meaning the immediate concern remains local privilege escalation and remote denial of service rather than a broadly exploitable remote takeover.

The Linux fix validates the routing header’s segments_left value before changing the header or advancing the associated address pointer. The upstream change is available through the Linux kernel Git repository .

TUNderflow: Virtual Network Headroom Calculation Causes Memory Corruption

TUNderflow, or CVE-2026-81000 , affects Linux TUN and TAP virtual networking devices.

TUN and TAP provide a bridge between userspace applications and the kernel networking stack through /dev/net/tun. They are widely used by virtual private networks, virtual machines, network emulators, containers and software-defined networking platforms.

Network devices frequently reserve additional memory before packet data—known as headroom—to store headers added later in the packet-processing path. Linux allows layered virtual devices to communicate these requirements through the networking stack.

In the vulnerable implementation, the TUN driver stored a supplied receive-headroom value without applying an adequate upper boundary. It then reused that value while deciding how much packet data should remain in the packet’s linear memory region.

Manizada found that a network configuration combining a netkit device, VXLAN, Open vSwitch and a raw TUN port could cause an unexpectedly large headroom value to reach the TUN driver. An internal calculation would underflow, after which other size calculations could wrap around and leave the packet-data pointer positioned outside its allocated memory.

Subsequent packet processing could then read or write beyond the legitimate buffer, creating a kernel-memory corruption primitive that could be developed into privilege escalation.

Exploitation requires TUN support and a networking path capable of forwarding the oversized headroom value. An ordinary user would also need permission to create unprivileged user and network namespaces, or a process would need CAP_NET_ADMIN inside an attacker-controlled namespace.

The patch for TUNderflow restricts receive headroom to values compatible with the kernel’s packet-buffer limits. It also introduces additional checks to ensure the expected bytes are present before the driver accesses them.

PPPoEject: Stale Pointer in PPP-over-Ethernet Processing

PPPoEject, tracked as CVE-2026-68121 , is a use-after-free-style memory corruption problem affecting the Linux implementation of Point-to-Point Protocol over Ethernet.

PPPoE remains in use in some broadband, telecommunications and network-access environments. When transmitting a PPPoE packet, the vulnerable pppoe_sendmsg() function created a kernel socket buffer, copied the payload and retained a pointer to the location where the PPPoE header would be written.

The kernel then called the lower network device to construct its own hardware header. The difficulty was that this operation could expand or reallocate the packet buffer, invalidating the pointer previously retained by the PPPoE code.

PPPoE continued using that old pointer after the original packet-buffer memory had been released or moved. Writes intended for the PPPoE header could therefore be redirected into memory that had subsequently been assigned to another kernel object.

The researcher’s exploit carefully coordinates several kernel and userspace operations to trigger the reallocation and reclaim the freed memory. It then converts the stale-pointer writes into control over a kernel object, ultimately allowing the attacking process to obtain root credentials.

The public PPPoEject proof-of-concept repository is tuned for selected Fedora 44 and Ubuntu 24.04 kernel builds and assumes a particular x86-64 environment. Its prerequisites include unprivileged user and network namespaces, access to FUSE and support for several networking components.

Those requirements limit opportunistic exploitation, but they should not be treated as dependable security boundaries. An attacker could modify the exploit for other distributions and kernel builds, while some containerized workloads may already possess the necessary networking capabilities.

Linux maintainers corrected the flaw by reacquiring the PPPoE header pointer from the socket buffer after the lower device completes header creation. The associated code also ensures that the relevant offset is updated if expansion moves the packet data.

DiagSpill: Integer Overflow Produces an Eight-Megabyte Overwrite

DiagSpill, assigned CVE-2026-74469 , affects the kernel’s Stream Control Transmission Protocol diagnostic functionality.

SCTP is a transport-layer protocol that supports features including multihoming, allowing one endpoint to be associated with multiple network addresses. Linux maintains a transport structure for each peer address connected to an SCTP association.

The sctp_diag component makes information SCTP sockets and their peer transports available through Linux’s socket-diagnostic and Netlink interfaces. Utilities such as ss use these interfaces to obtain socket information from the kernel.

The vulnerability resulted from a mismatch between the potential number of peer transports and the size of the field used to count them. An SCTP association could hold 65,536 transports, but the transport_count value was only 16 bits wide.

Adding the 65,536th transport caused the counter to wrap from 65,535 to zero. The diagnostic code consequently reserved no space for the peer-transport data, but it still copied the entire list into the response. According to the researcher, this could write approximately eight megabytes beyond the end of the allocated Netlink response.

The resulting corruption is particularly significant because DiagSpill does not require an unprivileged user namespace or special Linux capabilities. It only requires SCTP and sctp_diag to be available, making its basic kernel-corruption path less restricted than those of the other three vulnerabilities.

Manizada also warned that a process inside a container could potentially reach the host kernel through DiagSpill without special capabilities if the required SCTP features are accessible. Although the researcher did not develop the technique into a complete container escape, the shared-kernel architecture of containers means host-level memory corruption must be treated as a possible isolation failure.

There is also a conditional remote denial-of-service scenario. If SCTP address reconfiguration is enabled alongside certain authentication or unauthenticated address-addition settings, a malicious peer could attempt to create enough transports to overflow the counter. A process on the target would still need to issue the diagnostic request that triggers the overwrite.

These SCTP settings are disabled by default, and the researcher did not identify a credible path from that remote condition to root access. The Linux correction prevents the system from accepting another unique peer transport once the counter reaches its maximum value.

Container Environments Require Particular Attention

The findings have important implications for container security because containers the host’s Linux kernel. They do not provide the same hardware-enforced separation as conventional virtual machines.

Manizada reported that all four underlying bugs can corrupt the host kernel from inside a container if the required kernel functionality is exposed. DirtyAH6, TUNderflow and PPPoEject require suitable network capabilities when invoked from a container because the attacker generally cannot create a new user namespace in that situation. DiagSpill, however, may remain reachable without additional capabilities where SCTP and sctp_diag are present.

A successful kernel exploit launched inside a container could theoretically break through the container boundary and compromise the host, after which every workload running on that host could be exposed.

Security teams should therefore assess not only conventional Linux servers and endpoints but also Kubernetes nodes, container hosts, CI/CD runners, cloud development environments and other multi-tenant systems where untrusted or semi-trusted code may execute.

Mandatory Access Controls Did Not Stop the Exploits

Controls such as SELinux and AppArmor remain valuable layers of Linux protection, but administrators should not assume that they neutralize kernel memory-corruption vulnerabilities.

According to the researcher’s testing, SELinux and AppArmor did not prevent the four exploit chains. The principal exception involved Ubuntu’s AppArmor restrictions on unprivileged user-namespace creation, which can block the ordinary-user route to some namespace-dependent kernel attacks.

Once an exploit directly corrupts kernel memory, the attacker is operating below many of the policy controls enforced against ordinary userspace applications. This is why kernel updates remain the primary remediation.

Patches Available Across Stable Kernel Branches

The first upstream stable Linux releases containing fixes for all four vulnerabilities are:

Linux 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4.

These version numbers are useful when comparing upstream kernels, but enterprise administrators should rely primarily on advisories and packages from their Linux distributor. Vendors frequently backport individual security patches without changing to the corresponding upstream kernel version, so a lower-looking version number does not automatically mean that a system remains vulnerable.

Organizations should confirm that the installed kernel package contains fixes for all four CVEs and then reboot the machine into the updated kernel. Merely installing the package is insufficient if the vulnerable kernel remains loaded in memory.

The researcher’s oss-security disclosure contains the affected upstream version ranges, patch identifiers, technical prerequisites and links to each proof-of-concept repository.

Temporary Mitigations for Systems That Cannot Be Patched Immediately

Where immediate deployment is not possible, administrators can reduce exposure by disabling unprivileged user namespaces. This removes the most straightforward ordinary-user route to DirtyAH6, TUNderflow and PPPoEject.

It does not provide complete protection. Processes or containers with the necessary network capabilities may still reach the vulnerable paths, while DiagSpill does not depend on user namespaces.

Organizations should also consider disabling unused AH6/XFRM, TUN/TAP, PPPoE, SCTP and sctp_diag functionality. Removing or preventing unnecessary kernel modules from loading can materially reduce attack surface, particularly on servers with narrowly defined workloads.

The disclosure prompted a broader discussion on the oss-security mailing list whether Linux distributions should make uncommon networking modules less readily available by default. Independent security researcher Hanno Böck argued that custom kernels can avoid many current and future vulnerabilities by excluding functionality that an organization does not require.

Module blocking should be planned carefully because some virtual networking, VPN, container and telecommunications workloads legitimately depend on the affected components. Disabling them without testing could cause service outages.

Public Exploits Increase Pressure on Patch Management

There is currently no confirmed evidence in the cited disclosures that the four vulnerabilities have been exploited maliciously in the wild. Nevertheless, public proof-of-concept availability shortens the time and effort required for offensive teams and criminal groups to study the flaws.

The released exploits are not universally portable, and several have demanding configuration and memory-grooming requirements. That offers some protection against immediate mass exploitation, but it should not be interpreted as a long-term safeguard. Kernel exploitation techniques are frequently refined after initial publication, and attackers may combine them with other vulnerabilities to compromise exposed applications, containers or hosted development platforms.

Organizations should prioritize systems where untrusted users can execute code, user namespaces are enabled, containers run with elevated networking capabilities or multiple customers the same host kernel. Internet-facing servers that could provide an attacker with an initial low-privilege foothold should also receive urgent attention.

The immediate defensive action is straightforward: identify affected Linux assets, deploy vendor-supplied kernel updates, reboot into the corrected kernel and confirm that the running version includes fixes for CVE-2026-80844, CVE-2026-81000, CVE-2026-68121 and CVE-2026-74469 .

Cyber Security Hub

To view or add a , sign in

More articles by The Cyber Security Hub™