Four Linux Network Flaws Can Turn a Local User Into Root, and One Evades the Easy Mitigation

Update, 31 October 2026: Red Hat’s current bulletin says fixes have been released for many affected product streams, with remaining fixes being expedited. It also clarifies the limits of namespace controls, module blocking and default OpenShift protection. Those distinctions determine which systems remain exposed while kernel updates are deployed.

Four flaws reach four different network subsystems

DirtyAH6: IPv6 authentication-header processing

CVE-2026-80844 affects IPv6 AH6/XFRM processing. A malformed routing header can describe more remaining segments than the packet contains. Rearranging that header can then access an invalid memory range and corrupt kernel memory. A local user can build the attack configuration through unprivileged user and network namespaces; a process with CAP_NET_ADMIN and CAP_NET_RAW over an attacker-controlled network namespace can also reach the flaw.

Root escalation requires a complex AH6/XFRM setup and control of timing and memory layout. Red Hat says IPv6 routers or gateways that add AH in transport mode may also be remotely crashed. Remote privilege escalation would require substantially harder memory grooming, so this is not a claim that any remotely reachable Linux server can be taken over.

TUNderflow: oversized receive headroom

CVE-2026-81000 concerns the TUN/TAP driver. An oversized receive-headroom value propagated through a network-device path can wrap a size calculation, placing packet data outside its allocation and allowing heap corruption. A local attacker can arrange the necessary network configuration through unprivileged user and network namespaces, or from a process with CAP_NET_ADMIN over an attacker-controlled network namespace, to pursue root escalation. It is not directly reachable by untrusted remote callers on a default installation.

PPPoEject: a packet-buffer pointer outlives its allocation

CVE-2026-68121 affects PPPoE transmission. A lower-device header callback can replace a packet buffer’s backing allocation while PPPoE retains a pointer into the old allocation. A subsequent metadata write can therefore target freed memory. A suitable lower-device configuration, created through unprivileged user and network namespaces or a process with CAP_NET_ADMIN, can turn that corruption into local root escalation. Enterprise RHEL systems rarely use PPPoE by default, but inventory is more reliable than that general expectation.

DiagSpill: SCTP diagnostics do not need a new user namespace

CVE-2026-74469 concerns the SCTP diagnostics interface. A peer-transport count can wrap to zero for a sufficiently large association. The Netlink response is sized from that count, but the dump still emits data for every peer, producing an out-of-bounds write. The local privilege-escalation path needs SCTP and sctp_diag support, without requiring unprivileged user namespaces or special capabilities.

The remote denial-of-service path has additional conditions: ASCONF/ADD-IP must be enabled with SCTP-AUTH or net.sctp.addip_noauth_enable=1, and a local process must trigger the diagnostics request. Those SCTP options are disabled by default. Remote traffic alone is not the complete trigger.

Each vulnerability needs its own exposure assessment. They are four separate flaws, rather than one required exploit chain.

The shared mitigation stops only three local paths

Red Hat’s bulletin says disabling unprivileged user namespaces removes the ordinary-user namespace attack path for DirtyAH6, TUNderflow and PPPoEject. Processes or containers with the necessary network capabilities can remain able to reach them. This control does not mitigate DiagSpill. Organisations should also check whether the relevant ah6, tun, pppoe, sctp and sctp_diag modules are required.

Blocking an unused loadable module can remove that code path, but it does not disable functionality compiled directly into the kernel. Blocking modules can also break VPNs, virtual machines, container networking, broadband links or telecommunications workloads. The ah6 module supports IPv6 IPsec transport mode; tun supports TUN/TAP networking; pppoe supports broadband access; sctp and sctp_diag serve SCTP and its diagnostics. Review each independently. A loaded module may resist unloading while it is in use, and a reboot may be required. Patching is the comprehensive answer that closes the flaws while retaining required functionality.

RHEL is only the first layer of the inventory

Red Hat lists RHEL 6, 7, 8, 9 and 10, plus OpenShift Container Platform. Products using the RHEL kernel, including RHEL CoreOS and layered OpenShift, OpenStack and Virtualization environments, may also be affected. A container platform can therefore inherit the kernel issue even when the vulnerable code is not present inside an application image.

The current bulletin remains marked ongoing and says many affected product streams already have fixes, while the remaining fixes are being expedited. A fixed package for one release, architecture or kernel stream does not establish the state of another. Administrators should follow the current product-specific vendor errata and confirm that the corrected kernel is actually running after any required reboot.

Red Hat assesses default-configured OpenShift as Low risk for all four flaws. The default restricted-v2 Security Context Constraints limit the capabilities needed for the first three. DiagSpill still depends on SCTP and sctp_diag support being available. Workloads granted additional network capabilities or environments that explicitly enable the affected functionality may fall outside that default-risk assessment. Low risk is not the same as an unaffected underlying kernel.

Operational priorities

• Map the running kernel. Include hosts beneath container and virtualisation platforms.
• Identify required modules. Do not disable TUN/TAP or SCTP blindly on systems that depend on them.
• Apply the release-specific fix. Follow Red Hat’s live errata and verify the kernel after reboot.
• Use namespaces as a temporary reduction. Understand that it leaves DiagSpill and appropriately privileged paths exposed, and can disrupt container runtimes and sandboxed applications.
• Prioritise shared hosts. Multi-user systems and developer platforms make a local-to-root path more consequential.
• Review suspicious activity. Investigate unexplained privilege changes, kernel crashes and networking anomalies during the vulnerable period.

The quartet shares a headline, not one mitigation. Prioritise the release-specific corrections for all four and use compatible subsystem and namespace controls to reduce exposure while the rollout is pending. Verify the running kernel and the actual workload permissions before treating an asset as remediated.

Sources

• Red Hat security bulletin RHSB-2026-011, displayed public date 19 September 2026 at 15:00 and update date 26 September at 14:17; the page does not state a timezone.
• Red Hat CVE-2026-80844 product and remediation record.
• Red Hat CVE-2026-81000 product and remediation record.
• Red Hat CVE-2026-68121 product and remediation record.
• Red Hat CVE-2026-74469 product and remediation record.