Linux pedit COW CVE-2026-46331: page-cache LPE PoC drops in 24h

Researcher Massimiliano Oldani published a working local-root proof-of-concept named packet_edit_meme on June 17, 2026 for CVE-2026-46331 — an out-of-bounds write in the Linux kernel's act_pedit traffic-control action, nicknamed pedit COW. The kernel.org CNA assigned the CVE at merge time on June 16, weeks after the exploitable detail had already sat publicly on the netdev mailing list as a routine data-corruption fix. The weaponised PoC dropped less than 24 hours later, and The Hacker News re-amplified the chain on June 27.

If you run multi-tenant Linux hosts, Kubernetes nodes, shared CI runners, or any default-configured distro where unprivileged user namespaces are enabled, treat this as a kernel-patch fire drill — not a low-priority LPE.

The bug

The vulnerable code is tcf_pedit_act(), the kernel function that rewrites packet headers in flight via the act_pedit traffic-control module. The function follows a Copy-on-Write discipline — make a private copy of a memory page before editing it — but a sequencing error means it validates the writable range before runtime offsets are resolved. Certain edit keys determine their final offset only at execution time, so the write can land outside the private copy and directly into a shared page-cache page, including the page backing a cached executable on disk. The bug was introduced by commit 899ee91156e5 and is present from v5.18 through v7.1-rc6, patched in v7.1-rc7.

The Oldani PoC weaponises this in the classical page-cache-poisoning shape. A userns child with CAP_NET_ADMIN opens an act_pedit rule, drives the buggy code path, and overwrites the cached ELF entry of setuid-root /bin/su with a small shellcode — setgid(0) + setuid(0) + execve("/bin/sh"). The on-disk file is untouched; file-integrity checks come back clean while the next invocation of su yields a root shell from RAM. The exploit's only on-host requirements are that act_pedit is loadable and that unprivileged user namespaces are open — both default-on across most desktop distros and a large share of server defaults.

This is the companion bug to CVE-2026-43503 (DirtyClone), JFrog's June 25 page-cache LPE in the skb path. Both hit the page cache from opposite ends of the kernel within four days of each other; both ride unprivileged user namespaces; both publish working exploits ahead of any meaningful patch deadline.

Affected versions and patch status

Per the kernel.org commit and downstream advisories tracked by TuxCare and the cyberpress writeup:

• Upstream Linux kernel vulnerable on v5.18 through v7.1-rc6; fix lands in v7.1-rc7. Stable trees pick up from there.
• Red Hat Enterprise Linux ships errata RHSA-2026:27288 (RHEL 10), RHSA-2026:27789 (RHEL 9), RHSA-2026:27353 (RHEL 8), and RHSA-2026:27355 (8.8 EUS/TUS).
• Debian patched Trixie (13) via DSA-6355-1. Debian 11 (Bullseye) and 12 (Bookworm) remain unpatched as of June 25.
• Ubuntu lists 18.04, 20.04, 22.04, 24.04, 25.10, and 26.04 as vulnerable as of June 25; track Ubuntu's CVE-2026-46331 page for USN drops.
• CloudLinux has shipped a rebootless mitigation through KernelCare; plain stock kernels need the upgrade and reboot.

There is no remote vector. The attacker needs a local shell or in-container code execution; what they get is full root and, on container hosts where userns is the user/kernel boundary, a container escape.

Exploitation status

There is no CISA KEV listing for CVE-2026-46331 as of publication and no named in-the-wild exploitation has been attached to it yet. What there is:

• A public, working PoC at sgkdev/packet_edit_meme on GitHub, dropped within 24 hours of the CVE.
• Oldani's LinkedIn writeup and the thehackernews.com re-amplification — material for any operator on the kernel-LPE beat.
• The DirtyClone PoC four days earlier, which means any actor with a userns LPE playbook now has two complementary primitives, both targeting the page cache, both reaching root through the same setuid-binary vector.

Expect this CVE to surface in commodity post-exploitation toolkits within weeks. Linux container hosts and multi-tenant build infrastructure are the highest-priority cohort.

Action checklist

1. Check your exposure with three quick commands on each host:

   lsmod | grep -w act_pedit          # is act_pedit loaded right now?
   modinfo act_pedit                  # is it loadable on demand?
   sysctl user.max_user_namespaces    # RHEL family — is userns open?
   sysctl kernel.unprivileged_userns_clone   # Debian/Ubuntu — is userns open?
   

   Both act_pedit reachable AND unprivileged userns open == exploitable.

2. Patch and reboot the multi-tenant population first — shared developer servers, CI runners, Kubernetes worker nodes, any host where a local-shell or in-container primitive is cheap to obtain. A uname -r audit across the fleet is the only honest way to confirm the running kernel matches the patched package, not just the on-disk one.

3. If you do not need tc pedit rules, block the module from loading. This is the narrower mitigation and survives upgrades:

   echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
   

4. If you do not need rootless containers or unprivileged unshare, close the userns side. This breaks the exploit's setup phase across most LPE chains of the past two years, not just this one:

   # RHEL family
   sudo sysctl -w user.max_user_namespaces=0
   # Debian / Ubuntu
   sudo sysctl -w kernel.unprivileged_userns_clone=0
   

5. Container platforms: verify the host kernel under your nodes is on the patched build. A patched container image does not protect a vulnerable host kernel — the kernel is shared between every workload on the node.

6. Telemetry tells to watch for: unexpected unshare(CLONE_NEWUSER | CLONE_NEWNET) from non-root processes, sudden tc or nft invocations from web-application service accounts, root-process spawns whose parents look like user shells. Setuid binary integrity checks alone will not catch this — the page-cache poisoning never touches the file on disk.

Context

pedit COW and DirtyClone make this the second time in a single week that a working Linux kernel LPE shipping with a userns trigger and a page-cache poisoning primitive has dropped on the same fleet. That puts CVE-2026-46331 in a lineage that includes CVE-2024-1086 (nf_tables UAF, CISA KEV) and the more recent CVE-2026-23111 (nf_tables again, Exodus walkthrough in June). The structural lesson, again, is that unprivileged user namespaces plus a small kernel logic bug is the most weaponisable surface on modern Linux. The hardened fleets that turned off unprivileged_userns_clone years ago and never turned it back on are quietly enjoying the dividends of that decision; everyone else is on the patch-then-reboot treadmill.

The other structural detail worth flagging: the fix sat on the netdev mailing list for weeks as a routine data-corruption patch before it got a CVE. Patch-SLO clocks that start from CVE assignment have been losing time to that pattern for years. A bug class that ships exploits within 24h of the CVE will keep doing so for as long as the mailing list is treated as a public archive without a security gate.