A flaw in the Linux kernel's traffic-control subsystem can let a local unprivileged user gain root on affected systems.
CVE-2026-46331, nicknamed "pedit COW," is an out-of-bounds write in the packet-editing action (act_pedit) that corrupts shared page-cache memory. A public, working exploit appeared within a day of the CVE assignment on June 16. Red Hat rates the flaw as important.
The exploit never touches the file on disk. It poisons the cached copy of a setuid root binary (/bin/su) in memory, injects a small payload, and runs that altered image as root. File-integrity checks come back clean while a root shell is already open.
The exploit needs two things: act_pedit being loadable and unprivileged user namespaces being open, giving the attacker a namespace-local networking capability (CAP_NET_ADMIN) needed to trigger the bug.
On the tested RHEL and Debian targets, both conditions were present.
How the Bug Works
Linux's tc traffic-control tool can rewrite packet headers in flight using an action called pedit. The kernel function that does this, tcf_pedit_act(), is supposed to make a private copy of the data before editing it, the standard copy-on-write pattern.
It checked the writable range once, before the final offsets were known. Some edit keys only resolve their offset at runtime. When that happens, the write lands outside the privately copied region, so the kernel modifies a shared page-cache page instead of a private copy. If that page belongs to a cached file, the file's in-memory image is corrupted.
The pattern is familiar. Dirty Pipe, Copy Fail, DirtyClone, and Dirty Frag all share the same shape: a kernel fast path writes into a page it does not exclusively own, and the page cache takes the hit.
What is new here is the entry point. An unprivileged user can configure tc actions from inside a user namespace, which gives them the CAP_NET_ADMIN that the exploit needs.
Affected Systems
The PoC author reported unprivileged-to-root exploitation on RHEL 10 and Debian 13 (trixie), where unprivileged user namespaces are open by default. Ubuntu 24.04 required routing execution through AppArmor profiles that still permit user namespaces. Ubuntu 26.04 blocks that path by default because its AppArmor profiles restrict unprivileged user namespaces, though the underlying kernel remains vulnerable.
Fixes are split by vendor.
- Debian has fixed trixie through its security channel. Debian 11 and 12 are still listed as vulnerable.
- Ubuntu lists supported releases from 18.04 through 26.04 as vulnerable as of June 25.
- Red Hat lists RHEL 8, 9, and 10 as affected; RHEL 7 is not listed in the bulletin.
What to Do
Install the patched kernel and reboot. Prioritize systems where "local user" does not mean trusted user: multi-tenant hosts, CI/CD runners, Kubernetes nodes, build workers, and shared research or lab machines.
If you cannot patch yet, two mitigations kill the exploit chain. On systems that do not need tc pedit rules, check whether the module is in use (lsmod | grep act_pedit), then block it from loading:
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.confAlternatively, disable unprivileged user namespaces (user.max_user_namespaces=0 on RHEL, kernel.unprivileged_userns_clone=0 on Debian/Ubuntu). That removes the namespace-local capability the exploit needs, but it breaks rootless containers, some CI sandboxes, and sandboxed browsers. Test first.
Because the overwrite targets cached memory, file-integrity checks may not catch it. Dropping the page cache (echo 3 > /proc/sys/vm/drop_caches) clears the poisoned in-memory copy, but does nothing about the root shell the attacker already opened. Treat the host as compromised.
The fix landed on the netdev mailing list in late May, framed as a routine data-corruption patch. The exploitable detail sat on a public mailing list for weeks. No CVE, no security warning. The CVE was assigned when the fix was merged on June 16. The weaponized proof-of-concept followed within a day. For kernel page-cache corruption bugs, waiting for a scanner rule is too slow.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.