pedit COW (CVE-2026-46331) is a Linux local privilege escalation in the kernel's act_pedit traffic-control action. A missing-bounds-check write in tcf_pedit_act() performs a partial copy-on-write that lands in the shared page cache — letting an unprivileged local user overwrite the in-memory copy of a privileged binary like setuid-root /bin/su and walk straight to a root shell.

A public, author-verified proof of concept makes this turnkey on systems where the act_pedit action is reachable and unprivileged user namespaces are available. The CVE was assigned at merge time on June 16, 2026, and a weaponized PoC dropped June 17. Red Hat rates it Important.

What the Vulnerability Is

The tcf_pedit_act() function in net/sched/act_pedit.c is supposed to make a packet's memory page private before editing packet headers (a normal copy-on-write). The bug: it computes its COW range once, up front, and misses the additional runtime offset that typed keys add when the edit actually executes. The write then lands outside the range it made private — a partial COW that corrupts a page still shared with the page cache.

That shared page cache is the same memory the kernel uses to hold the in-RAM image of on-disk files, including executables. By steering the corrupting write at the cached image of a setuid-root binary, an attacker rewrites the binary's behavior in memory only — the on-disk file is untouched, so on-disk integrity monitoring sees nothing.

The public PoC chains four pieces: unprivileged user namespaces, a traffic-control configuration that reaches act_pedit, zero-copy file references, and page-cache targeting. It poisons the cached image of /bin/su and uses it to launch a root shell.

Why It Matters

  • It's a full local root. Any unprivileged user who can reach the act_pedit action gets a clean path to root on an affected, unpatched system.
  • User namespaces make it broadly reachable. Exploitation needs CAP_NET_ADMIN, but that's routinely obtainable inside an unprivileged user namespace — enabled by default on RHEL and Debian. That turns "needs a capability" into "needs a shell."
  • It defeats file-integrity monitoring. Because the attack corrupts the page-cache copy and never writes to disk, AIDE/Tripwire-style on-disk integrity checks won't flag it.
  • The patch shipped looking routine. The fix circulated as an ordinary data-corruption bug fix before its security implications were understood — which is why a working exploit landed within a day of the CVE.

Am I Affected?

Confirmed-vulnerable builds reported include RHEL 10 (6.12.0-228.el10) and RHEL 8/9; Debian 13 trixie (6.12.90+deb13.1) and Debian 11/12; and Ubuntu 24.04.4 (6.17.0-22) through the 18.04–26.04 range. You are realistically exploitable if the host runs an affected kernel, the act_pedit module is loadable/reachable, and unprivileged user namespaces are enabled (the default on RHEL/Debian).

Remediation

Patch and reboot — first choice

RHEL 8/9/10 and Debian 13 have shipped fixed kernels; mainline and stable branches are fixed. Install the vendor kernel that explicitly references CVE-2026-46331 and reboot.

If you can't patch immediately, blacklist the module

If you don't use tc pedit rules — most servers don't — block the module from loading:

echo "blacklist act_pedit" > /etc/modprobe.d/blacklist-act-pedit.conf

Then unload it if already loaded (modprobe -r act_pedit) and confirm nothing in your networking stack depends on it.

Restrict unprivileged user namespaces

Closing the namespace path removes the easy route to CAP_NET_ADMIN. Where your workloads don't require it:

# Debian/Ubuntu style
sysctl -w kernel.unprivileged_userns_clone=0

# Broadly applicable
sysctl -w user.max_user_namespaces=0

Test first — containers, browsers, and some sandboxes rely on user namespaces.

Quick-Win Checklist

  • Install the vendor kernel that cites CVE-2026-46331 and reboot.
  • If unpatched: blacklist act_pedit via modprobe and unload the module.
  • Disable unprivileged user namespaces where workloads don't need them.
  • Inventory which hosts give local shells to untrusted users — patch those first.
  • Don't rely on on-disk file-integrity monitoring to detect this — it won't.
  • Confirm no tc pedit rules are in use before blacklisting the module.

Sources