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

This tracker is no longer updated. Every maintained upstream stable line carries the fix, as do Debian, Proxmox VE 9’s default kernel, every tracked NixOS ref, Rocky Linux / RHEL 10, 9 and 8, and all three Amazon Linux 2023 kernel streams — install a fixed kernel and reboot into it.

Summary

✅ A local root exploit is public, and every tracked distribution ships a fixed kernel. 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. Red Hat has shipped fixes for RHEL 8 across its EUS/AUS/E4S streams (RHSA-2026:71329 and companions, covering kernel-rt too), for RHEL 9’s current 9.8 stream (RHSA-2026:71700), and for RHEL 10’s current 10.2 stream (RHSA-2026:71602), and Rocky Linux has rebuilt all three fixes. Proxmox VE 9’s default kernel carries the fix through its Ubuntu base. A host is safe only once it has installed a fixed kernel and rebooted into it; until then, 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.

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. Red Hat has shipped RHSAs fixing RHEL 8’s kernel across its EUS/AUS/E4S streams, RHEL 9’s current 9.8 stream, and RHEL 10’s current 10.2 stream, and Rocky Linux has rebuilt all three fixes. Proxmox VE 9’s default kernel carries the fix through its Ubuntu base.

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 each row’s newest build when the tracker was last updated.

Linux kernel

The fix reached mainline in v7.2-rc5 and has been backported to every maintained stable line.

7.1.x is end of life. Every release from 7.1.6 on carries the fix, but the line gets no further updates — move to 7.2.x or a long-term line.

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

bullseye (Debian 11) left LTS support on 2026-08-31 and no longer gets security updates. Its last kernel is unpatched — upgrade to 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. PVE 9’s default proxmox-kernel-7.0 is built from Ubuntu’s resolute (7.0) kernel sources, and its rebase onto Ubuntu-7.0.0-38.38 brought the fix in with that build’s upstream stable updates — Proxmox’s own changelog names no PPPoE fix.

• PVE 8 reached end of life in August 2026, before any fix reached its kernels. Its default proxmox-kernel-6.8 and its opt-in series stay vulnerable, and no fix is coming — upgrade to PVE 9.
• Superseded series that PVE 9 still publishes, such as proxmox-kernel-6.17 and proxmox-kernel-6.14, ride unpatched Ubuntu bases and will not get the fix. A host booting one should move to the default proxmox-kernel-7.0.

NixOS

Every NixOS channel and branch in the table defaults to linux_6_18 (linuxPackages), which carries the fix. 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.

Kernel updates land on nixpkgs master first and reach each channel once its Hydra jobset passes, so a channel can sit a few days behind master. The -small channels (nixos-unstable-small, nixos-26.05-small) run a reduced jobset and pick up kernel updates fastest.

Which ref a flake input follows:

• github:NixOS/nixpkgs/nixos-unstable and github:NixOS/nixpkgs/nixos-26.05 follow those channels — the GitHub channel branches are updated to exactly the published channel pins.
• A bare github:NixOS/nixpkgs with no ref follows master, and github:NixOS/nixpkgs/release-26.05 follows that branch. Both are ungated development branches — they carry a kernel bump as soon as it lands, often a day or more before a channel publishes it.
• A bare nixpkgs registry input resolves by default to the nixpkgs-unstable channel: a separate channel aimed at Nix on other operating systems, not gated on the NixOS tests.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks that carry the vulnerable PPPoE code; the flaw predates git history, so even EL8’s 4.18 kernel is in-window.

Red Hat advisories beyond the current minor-release kernels in the table:

• RHEL 10: 10.0 E2S RHSA-2026:71599.
• RHEL 9: 9.6 EUS RHSA-2026:71631; 9.4 E4S RHSA-2026:71569; 9.2 E4S RHSA-2026:71601 (NFV kernel-rt RHSA-2026:71606).
• RHEL 8: 8.10 kernel-rt RHSA-2026:71330; 8.8 E4S/TUS RHSA-2026:71594; 8.6 AUS RHSA-2026:71592; 8.4 AUS RHSA-2026:71565.
• RHEL 7 ELS: RHSA-2026:71687 (kernel-rt RHSA-2026:71657).
• RHEL 6 ELS: RHSA-2026:71649.

On RHEL 9 and 10 the real-time kernel (kernel-rt) is fixed by the same advisories as the regular kernel; RHEL 9.2 E4S, 8 and 7 have separate kernel-rt advisories, listed with the kernel’s.

AlmaLinux, CloudLinux and Oracle Linux’s Red Hat Compatible Kernel rebuild RHEL’s kernel, so they get the fix as they rebuild Red Hat’s advisories.

Amazon Linux

The three AL2023 streams are the default kernel package (6.1 line) and the opt-in kernel6.12 and kernel6.18 packages. Amazon builds carry their own cherry-picks, so a stream can be fixed at a build below its line’s upstream first-fixed release — judge an AL2023 kernel by its ALAS, not its version number.

Amazon Linux 2 reached end of support on 2026-06-30 and gets no fix — migrate to AL2023.

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.
• Every tracked distribution ships a fix; unrebooted hosts remain exposed. The fix reaches every maintained upstream stable line, and Debian, Proxmox VE 9, all tracked NixOS refs, Amazon Linux 2023, and the whole Rocky Linux / RHEL family (8, 9, and 10) have adopted it. Check the running kernel against the First fixed column, not the kernel’s age.
• 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