Linux act_pedit OOB Write Poisons Page Cache, Hands Local Users Root

Key points

• CVE-2026-46331 is an out-of-bounds write in the Linux kernel's act_pedit packet-editing action.
• An unprivileged local user with CAP_NET_ADMIN in a user namespace can corrupt shared page-cache memory backing on-disk files.
• The exploit poisons the cached copy of a privileged binary rather than hijacking kernel control flow.
• A working public exploit appeared within a day of CVE assignment on 16 June.
• Red Hat rates the flaw High severity under their advisory.

How does the exploit actually work?

The bug lives in act_pedit, the packet-editing action exposed through the tc netlink interface. An unprivileged user holding CAP_NET_ADMIN inside a user namespace (granted by default on most desktop distributions) can write past a kernel-side buffer boundary and corrupt shared page-cache memory that backs on-disk files.

The kernel serves the poisoned page back to userland without complaint. SUID binaries such as /usr/bin/su and /usr/bin/pkexec are the obvious targets in the PoC, though anything mapped read-only and executed with elevated privileges is fair game. We reported a structurally similar primitive in June when DirtyClone corrupted file-backed memory through a cloned skb; this exploit follows the same playbook with a different entry point.

The CVE was assigned 16 June. The bug was reported by researcher Lin Ma.

Should you patch or mitigate first?

Patch first. If that isn't immediately possible, two mitigations reduce exposure. Disabling unprivileged user namespaces closes the entry point: on Debian and Ubuntu set sysctl kernel.unprivileged_userns_clone=0; RHEL users set sysctl user.max_user_namespaces=0 instead. Blacklisting the act_pedit module also works if traffic shaping isn't in use: add install act_pedit /bin/true to /etc/modprobe.d/blacklist-pedit.conf.

Forensically, page-cache poisoning doesn't touch disk. A reboot clears the corruption, which is itself a tell if you're reviewing audit logs. Watch for tc filter add calls from non-root UIDs.

Should container operators worry?

Yes. The bug is reachable from inside containers that hold CAP_NET_ADMIN, which covers most Kubernetes CNI sidecars and any pod running with hostNetwork: true. Default Docker containers without --privileged or --cap-add=NET_ADMIN are not affected.

The PoC is reliable, the exploit primitive is generic, and page-cache corruption evades most EDR products that watch for control-flow hijacks rather than cache integrity. That combination is what makes this one worth treating as urgent rather than routine.