Four newly disclosed Linux kernel network-stack vulnerabilities can allow a local user to escalate privileges to root when the required subsystem and exploitation prerequisites are present. The flaws are CVE-2026-80844 (DirtyAH6), CVE-2026-81000 (TUNderflow), CVE-2026-68121 (PPPoEject) and CVE-2026-74469 (DiagSpill). Public proof-of-concept exploits and upstream fixes are available, while Red Hat has confirmed that RHEL 7, 8, 9 and 10 are affected and says fixes are being expedited.
The four vulnerabilities should not be treated as identical. DirtyAH6, TUNderflow and PPPoEject generally require unprivileged user/network namespaces or equivalent networking capabilities for the usual local exploitation path. DiagSpill is the important exception: Red Hat says it does not require unprivileged user namespaces or special capabilities in the same way, making its exposure model broader when the SCTP diagnostic functionality is available.
Linux kernel exposure differs across the four flaws
| Vulnerability | Subsystem | Main local prerequisite | Important boundary |
|---|---|---|---|
| DirtyAH6 — CVE-2026-80844 | IPv6 AH6 / XFRM | User/network namespaces or relevant networking capabilities | Do not describe it as an ordinary remote-root vulnerability. |
| TUNderflow — CVE-2026-81000 | TUN/TAP | User/network namespaces or CAP_NET_ADMIN in a controlled network namespace | The vulnerable TUN/TAP path must be reachable. |
| PPPoEject — CVE-2026-68121 | PPPoE | User/network namespaces or CAP_NET_ADMIN in a controlled network namespace | Exposure depends on PPPoE functionality being available. |
| DiagSpill — CVE-2026-74469 | SCTP / sctp_diag | No equivalent user-namespace prerequisite | Red Hat identifies it as the higher-risk member of the quartet; remote denial of service may be possible in specific SCTP configurations. |
This prerequisite difference is why a single statement such as “four remotely exploitable Linux root flaws” would be misleading. All four can produce local privilege escalation under the right conditions, but the reachable attack surface is different for each one.
Which upstream kernels contain all four fixes?
The coordinated disclosure identifies the first upstream stable releases containing all four fixes as 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. These numbers are useful for upstream or directly maintained kernels, but they must not be used as a simple pass/fail comparison for enterprise distributions.
RHEL and other Linux distributions commonly backport security fixes while keeping a vendor-specific kernel version. A RHEL administrator should therefore check the current Red Hat security advisory and errata for the installed release stream instead of assuming that a kernel is vulnerable merely because its version number appears lower than an upstream fixed release.
What Red Hat users should verify
Red Hat’s RHSB-2026-011 lists RHEL 7, 8, 9 and 10 as affected. Layered products that use an affected RHEL kernel can also inherit the exposure. Exact fixed package builds can differ between release streams and may continue changing while Red Hat completes remediation.
Administrators should first identify the installed vendor kernel and current security errata, then determine whether the relevant networking subsystem is present and reachable. For the first three flaws, the availability of unprivileged user namespaces or equivalent capabilities materially changes the standard local attack path. For DiagSpill, disabling unprivileged user namespaces alone does not remove the vulnerable path.
Interim mitigations are not interchangeable
Red Hat documents mitigations based on reducing access to the vulnerable functionality, including disabling relevant kernel modules where operationally acceptable. Disabling unprivileged user namespaces can reduce exposure to DirtyAH6, TUNderflow and PPPoEject, but it is not a mitigation for DiagSpill.
These mitigations can have real production consequences. User namespaces may be required by containers and sandboxing. TUN/TAP is commonly used by VPN, virtualization and networking workloads. PPPoE and SCTP can also be legitimate production dependencies. TPS therefore does not recommend disabling a subsystem without first verifying that the workload can operate without it.
Are the four flaws being exploited in the wild?
Public proof-of-concept exploit code is available from the coordinated disclosure, which raises the practical importance of patching and exposure review. However, the evidence reviewed by TPS did not establish active exploitation in the wild. Public PoC availability and confirmed real-world exploitation are different security states and should not be presented as the same thing.
What administrators should do now
Start with the distribution vendor rather than the upstream kernel number. Verify whether the installed kernel package is affected, check whether the relevant subsystem and exploitation prerequisites exist, and apply the vendor-supported fixed kernel when available. If a patched package is not yet available, evaluate Red Hat’s documented module or namespace mitigations against the actual workload before making a production change.
This page should be updated on the same URL as Red Hat publishes or revises fixed package builds, other major distributions complete remediation, authoritative exploitation evidence appears, or CISA adds any of the four CVEs to the Known Exploited Vulnerabilities catalog.