PPPoEject (CVE-2026-68121) — Linux PPPoE sendmsg use-after-free

Summary

⚠️ A local root exploit is public and several tracked distributions are still unpatched. The fix ships in every maintained upstream stable line (mainline, 7.2, 7.1, 6.18, 6.12, 6.6, 6.1, 5.15, and 5.10). Debian’s sid, forky, trixie, and bookworm carry it, all seven tracked NixOS refs have rebased onto the fixed 6.18 build, and all three Amazon Linux 2023 kernel streams have shipped it. Proxmox VE 8 and 9 and the Rocky Linux / RHEL family are still vulnerable at the time of writing — Red Hat has no fix yet for RHEL 8, 9, or 10 (only the niche RHEL 8 kernel-rt package is marked “Will not fix”). Treat any host where an unprivileged user or a container can reach CAP_NET_ADMIN in a namespace as directly exposed, and apply the mitigations below until a patched kernel is available.

How the exploitation chain works

pppoe_sendmsg() builds a socket buffer, copies the user payload into it, and then calls dev_hard_header() so the lower network device can construct its link-layer header before PPPoE fills in its own header. The function saves a pointer to the PPPoE header before that call and reuses it after — but a device header callback is allowed to reallocate the skb head with pskb_expand_head(), which frees the old head and invalidates any pointer into it. The subsequent six-byte header memcpy() and the ph->length store then write through that stale pointer into freed slab memory.

The trigger is a race the attacker drives deliberately. A PPPoE send is blocked inside copy_from_user() on an attacker-owned FUSE page; meanwhile the first non-Ethernet port — a GRE or IP6GRE device — is added to an empty team (or bonding) device. The team’s delegated header callback then expands the skb head, “ejecting” the old head while pppoe_sendmsg() still holds a pointer into it. When the blocked copy completes, the header write lands in the freed head.

From that use-after-free the public exploit builds a chain to root:

1. Groom. An AF_PACKET TX-ring carrier is filled with fake struct file objects, and a populated file-descriptor table is groomed into the allocation that will be freed.
2. Free. A PPPoE send is stalled on a FUSE page, then a GRE/IP6GRE port is added to an empty team (Fedora) or bonding (Ubuntu) device, making dev_hard_header() reallocate and free the skb head.
3. Corrupt. The stale PPPoE header write redirects one live fdtable entry to the attacker-built fake struct file.
4. Escalate. Closing that descriptor runs a controlled kernel callback, which installs root credentials and opens /bin/sh -p.

The fix, e9c238f6fe42, reloads the PPPoE header through the skb’s network-header offset after dev_hard_header() returns — pskb_expand_head() updates that offset when it relocates the head — so the write always targets the live head.

ℹ️ Only the kernel backport flips a verdict here. The flaw is entirely in kernel code and the fix is a single commit, so a row is Fixed only when its kernel carries e9c238f6fe42. There is no not-affected case: the bug predates git history, so every supported kernel line is in-window. The reachability conditions (unprivileged user namespaces, PPPoE, FUSE, team/bonding + GRE) decide who can reach an unpatched kernel — they are prose, never a column, and never downgrade a verdict.

Vulnerable commit range

The reachable lifetime therefore spans 2.6.12 through 7.1.5 (and mainline before v7.2-rc5). A kernel is safe only by carrying the fix.

Patch status

A row is Fixed only if its kernel carries the e9c238f6fe42 backport — a release at or past its branch’s first-fixed version, or an explicit distro cherry-pick. Every maintained upstream stable line now carries the fix (see the Linux kernel rows), including the 7.2.x stable branch, which was cut after the fix had already landed. Debian’s sid, forky, trixie, and bookworm have rebased onto it, all seven tracked NixOS refs default to the fixed 6.18 build, and all three Amazon Linux 2023 kernel streams have shipped it; Proxmox VE 8 and 9 and the Rocky Linux / RHEL family remain Vulnerable.

The first group is the upstream kernel; the rest are a focused set of x86-64 distributions, with per-distribution detail in the sections that follow. Current kernel is live; First fixed and Fixed since stay — until a row is fixed.

Linux kernel

The fix reached Linus in v7.2-rc5 (tagged 2026-07-26). It was backported the same day it was authored to every maintained stable line, and the releases followed in two batches: 7.1.6, 6.18.42, 6.12.101, and 6.6.148 on 2026-08-03, then 6.1.183, 5.15.216, and 5.10.265 on 2026-08-19. A new 7.2.x stable branch was later cut from v7.2 (2026-08-16), which already contained the fix — so every 7.2.x release carries it. The 7.1.y line has since reached end-of-life at 7.1.13, but every release from 7.1.6 onward carries the fix, so a host pinned to 7.1.y stays fixed. Every maintained upstream branch is now fixed; the remaining exposure is entirely at the distribution layer.

To confirm a tree directly, the fix adds a single ph = pppoe_hdr(skb); reload after the dev_hard_header(skb, dev, ETH_P_PPP_SES, …) call in pppoe_sendmsg() (drivers/net/ppp/pppoe.c); a tree missing that line is unpatched.

Debian

Debian’s status splits on which upstream branch each suite tracks. sid reached the fix with the 7.1.6-1 upload (7.1.6 is the 7.1 line’s first-fixed release), first seen in the archive 2026-08-04, and has since moved on to the 7.2 line — still fixed. forky (testing, the future Debian 14) reached the fix on the 7.1 line: it migrated onto a fixed 7.1 kernel on 2026-08-17, so it is fixed too.

trixie (Debian 13) rides the 6.12 line and shipped 6.12.101-1 — its line’s first-fixed release — as a trixie-security update, so it is fixed; the security tracker records the fix. bookworm (Debian 12, the 6.1 line) is fixed too: bookworm-security published 6.1.187-1, repackaging the upstream 6.1.187 release, past the line’s 6.1.183 first fix, first seen in the archive 2026-09-08.

bullseye (Debian 11) reached the end of its LTS window on 2026-08-31 and has dropped out of Debian’s active security support — it no longer appears in the security tracker or the archive’s package index, so no DSA for this CVE will reach it. Its last published kernel remains unpatched; the only way out for a host still on it is to upgrade to a supported release (bookworm or trixie).

The pppoe, team, and bonding modules Debian ships autoload on demand and are not blacklisted by default, so a Debian host with unprivileged user namespaces enabled exposes the unprivileged local path.

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over; whether a PVE kernel carries the fix tracks its Ubuntu base. PVE 9’s default proxmox-kernel-7.0 and PVE 8’s default proxmox-kernel-6.8 are both still vulnerable: neither packaging carries a named PPPoE cherry-pick, and Ubuntu’s security tracker has not yet released a fixed build for the corresponding series — resolute (the 7.0 base) is marked pending and noble (the 6.8 base) is needed. A PVE 9 build rebased onto a resolute base that names the fix as released, or a named Proxmox cherry-pick, will flip PVE 9; the analogous signal will flip PVE 8.

PVE 9 and PVE 8 also publish older opt-in / preview kernel series (proxmox-kernel-6.17, -6.14, -6.11 and the like) that ride equally unpatched Ubuntu bases; a host booting one of those is vulnerable until it moves to a fixed kernel.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18. The 6.18.y line has a fixed release (6.18.42), and the nixpkgs master and release-26.05 branches picked it up on 2026-08-03 — both are fixed. The five republishing channels have all picked up the fix as well, each once its Hydra jobset passed: nixos-unstable-small and nixos-26.05-small first (the -small channels ride a reduced jobset and typically lead), then nixos-unstable, nixos-26.05, and nixpkgs-unstable. Every tracked NixOS ref is now fixed. The nixpkgs-unstable channel — what a bare nixpkgs flake registry input resolves to — is a separate channel aimed at Nix users on other operating systems.

A host that overrides boot.kernelPackages to an older series (linux_6_1 / linux_5_15 / linux_5_10) is fixed only if that series is at or past its own first-fixed release; the tracked default is the fixed 6.18 build.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks that carry the vulnerable PPPoE code. Red Hat’s CVE record (CSAF/VEX, initial release 2026-08-10) marks RHEL 8, 9, and 10 affected and ships no fix for the base kernel package on any of them — no RHSA yet. So every in-support EL stream is vulnerable. Red Hat rates the flaw Moderate, scoring the integrity impact lower than the demonstrated local-root exploit (I:L versus the CNA’s I:H). Rocky rebuilds RHEL unchanged, so its status tracks Red Hat’s; AlmaLinux (typically the fastest rebuild) has published no erratum either. Oracle Linux and CloudLinux track the RHEL determination.

Unlike some kernel CVEs, this bug has no not-affected EL base: the flaw predates git history, so even EL8’s 4.18 kernel is in-window. The niche kernel-rt real-time kernel shares the base kernel’s exposure — RHEL 8’s kernel-rt is the one package Red Hat has explicitly flagged “Will not fix,” while the base kernel it shares its source with remains open (no fix planned yet, but not ruled out). Because Red Hat has no fix for any in-support stream’s base kernel, the practical response on EL hosts is the mitigations below.

Amazon Linux

Three advisories fixed CVE-2026-68121 across the AL2023 kernel streams: ALAS2023-2026-2143 (2026-09-14) in the default kernel stream, ALAS2023-2026-2110 (2026-08-31) in the kernel6.12 opt-in stream, and ALAS2023-2026-2106 (2026-08-31) in the kernel6.18 opt-in stream. All three are fixed. Amazon builds carry their own cherry-picks, so a stream can be fixed at a build below its line’s upstream first-fixed release. Amazon Linux 2 reached end of support on 2026-06-30 and is not tracked.

Detection

Is the running kernel in the affected window and missing the fix? Every kernel below its line’s first-fixed release is in-window. Compare the running kernel against the Patch status table’s First fixed column for its series:

uname -r

Can an unprivileged user reach CAP_NET_ADMIN? The unprivileged local path needs unprivileged user namespaces. If either of these is non-zero, an ordinary user can unshare -Urn into a namespace where it holds CAP_NET_ADMIN:

sysctl kernel.unprivileged_userns_clone user.max_user_namespaces

Are the modules the trigger needs available? The chain needs PPPoE, a team or bonding device, a GRE/IP6GRE lower device, and FUSE. modinfo prints the on-disk path of each named module (an error for any absent):

modinfo -F filename pppoe team bonding ip_gre ip6_gre fuse

Is this a multi-tenant or container host? Any context where an unprivileged user, or a container holding CAP_NET_ADMIN (for example one run with --cap-add=NET_ADMIN or a privileged pod), can configure network devices is directly exposed, regardless of the user-namespace sysctls:

grep -rEl 'CAP_NET_ADMIN|NET_ADMIN|privileged' /etc/containers /etc/kubernetes 2>/dev/null

Public PoC

There is a public working exploit. manizada/PPPoEject ships pppoeject_root_repro.py, a self-contained program that escalates an unprivileged user to a root shell by driving the PPPoE race and the chain described above. The author reports it targeting Fedora 44 (6.19.10-300.fc44, via a team device) and Ubuntu 24.04 (6.8.0-124/-136-generic, via a bonding chain). Do not run it on a system you are not authorised to test — the author warns it is destructive and should run only in a disposable VM.

The exploit needs a fairly specific environment — x86-64 with RDTSCP and KPTI/PTI inactive, at least four logical CPUs, read/write access to /dev/fuse, unprivileged user and network namespaces with CAP_NET_ADMIN and CAP_NET_RAW, and PPPoE / IP6GRE / AF_PACKET / team (Fedora) or bonding (Ubuntu) support — but those are ordinary defaults on many desktop and server kernels. A working exploit being public means this should be treated as exploited-in-practice: patch or apply the mitigations below.

Mitigation

The real fix is a patched kernel (a release at or past v7.2-rc5 / 7.1.6, or a distro backport of e9c238f6fe42). Until one is installed, the exposure can be narrowed — none of these is a fix.

Restrict unprivileged user namespaces

The unprivileged local path depends on user namespaces to obtain CAP_NET_ADMIN. Where unprivileged user namespaces are not needed, disabling them closes that path (it does not stop a process or container that already holds CAP_NET_ADMIN). On Debian/Ubuntu kernels:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Persist it across reboots:

echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-cve-2026-68121.conf

On kernels without that Debian/Ubuntu knob, cap the count instead:

sudo sysctl -w user.max_user_namespaces=0

Block the PPPoE module

Where PPPoE is not used, blocking the module removes the vulnerable send path. install … /bin/false is surer than a plain blacklist, which only suppresses alias autoloading:

printf 'install pppoe /bin/false\n' | sudo tee /etc/modprobe.d/cve-2026-68121.conf

That rule only prevents future autoload — it does not remove a module already resident. Where pppoe is loaded but idle, unload it so the block takes effect now:

sudo modprobe -r pppoe

The disclosure cautions that blocking PoC-specific modules is not a proper mitigation on its own — the underlying flaw is in pppoe_sendmsg(), and other device-callback paths could reach it — so treat this as a stopgap where PPPoE is genuinely unused, and patch as soon as possible.

Restrict who holds CAP_NET_ADMIN

On multi-tenant and container hosts, review which workloads are granted CAP_NET_ADMIN: drop it from container capability sets that do not need it, avoid privileged containers, and keep untrusted workloads out of namespaces where they can configure network devices. This shrinks the reachable surface but leaves a trusted-but-hostile caller in scope.

Risk notes

• Multi-tenant and container hosts are the exposure. The demonstrated impact is local privilege escalation to root, so any host where an unprivileged user or a container can reach CAP_NET_ADMIN and configure network devices is directly in scope — a public exploit exists.
• Several distributions remain unpatched. The fix reaches every maintained upstream stable line, and Debian, all tracked NixOS refs, and Amazon Linux 2023 have adopted it, but both Proxmox VE releases and the Rocky Linux / RHEL family are still vulnerable. Check the First fixed column, not the kernel’s age.
• Red Hat has no fix for the in-support streams. RHEL 8, 9, and 10 all have no RHSA for the base kernel (only RHEL 8’s niche kernel-rt is marked “Will not fix”), so EL hosts should rely on the mitigations rather than waiting for an erratum.
• Part of a set of four. PPPoEject was disclosed alongside DirtyAH6, TUNderflow, and DiagSpill; a host exposed to one is often exposed to the others. The first stable releases carrying 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.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the git reference, advisory, or repository index that established each fact — so any row can be audited or reproduced. Most readers never need it.

References