On June 17, 2026, researcher Massimiliano Oldani published a working proof-of-concept named packet_edit_meme for a Linux kernel local privilege escalation now tracked as CVE-2026-46331 and nicknamed pedit COW. The flaw is in the kernel’s traffic-control (tc) subsystem. Any unprivileged local user on an affected host can use it to gain root in a single command.
pedit COW is a separate, new bug in a different part of the kernel, the traffic-control act_pedit action in net/sched, not the XFRM/ESP path behind Dirty Frag and Fragnesia. The module blacklist you may have applied for those does not cover this vulnerability. The mitigation below targets a different module (act_pedit).
Don’t want to schedule another emergency reboot?
pedit COW requires patching and rebooting affected hosts. If emergency kernel reboots are hard to schedule across a fleet, KernelCare is the alternative we recommend. It applies kernel security fixes to a running server with no reboot and no maintenance window. Once the pedit COW livepatch is published, KernelCare-subscribed servers receive it automatically. See Stream 3 below for current status.
The vulnerable code is the act_pedit traffic-control action, which edits packet headers in place. It computes its copy-on-write (COW) range once, before editing, but misses the runtime offset that typed keys add at execution time, so it ends up writing into a page it never made private. This partial COW lets the write reach shared page-cache memory backing a real file, which the kernel believed it had made safe to modify. By controlling the offset, an unprivileged process turns this into a write into the page-cache copy of a file it could otherwise only read. The CAP_NET_ADMIN capability needed to configure the action does not require real privilege: it is obtained inside an unprivileged user + network namespace, which is available to ordinary users by default on the EL family.
The published PoC targets setuid-root /bin/su directly: it overwrites the cached ELF entry point of the binary with shellcode equivalent to setgid(0); setuid(0); execve(“/bin/sh”), so the next su invocation runs as root.
Details: public PoC · upstream fix · Red Hat CVE entry · Ubuntu CVE entry · TuxCare analysis
Status as of June 26, 2026, 13:00 UTC
Patched kernels are released for CloudLinux 9 and CloudLinux 10 (stable) and for CloudLinux 7h and CloudLinux 8 (beta, rolling out to stable). For CloudLinux for Ubuntu 22.04 LTS, the fix depends on the Canonical kernel update. KernelCare livepatches are in active build/test as a rebootless route. See Update instructions below for current per-stream status. This article will be updated in place as each stream reaches release.
A KernelCare livepatch that deploys the fix without a reboot will also be available as an alternative on all affected versions. See Stream 3 below for current status.
Until a patched kernel or KernelCare livepatch is installed, apply one of the two mitigations below. Either one closes the attack; choose the one that fits your workload.
If you do not use traffic-control pedit rules (the typical web-hosting server does not), prevent the module from loading and unload it if it is already present:
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
lsmod | grep -w act_pedit && sudo rmmod act_peditTo revert after a patched kernel is installed:
sudo rm /etc/modprobe.d/disable-act_pedit.confCompatibility: with this rule in place, any traffic-control configuration that uses the pedit action will fail to load. Do not apply it on hosts that rely on tc … action pedit rules.
This removes the CAP_NET_ADMIN acquisition path the exploit relies on, without touching the tc subsystem.
On the EL family (CL7h, CL8, CL9, CL10):
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.confOn CloudLinux for Ubuntu 22.04:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.confCompatibility: unprivileged user namespaces are required by rootless container runtimes and several CI sandboxes. Restricting them is acceptable on hardened or hosting workloads, but disruptive on developer and container hosts. Do not apply this option where those workloads run.
The exploit modifies a legitimate system binary (the public PoC overwrites /bin/su) in the page cache as part of gaining root, so applying a mitigation alone is not enough on systems that may have been targeted before the mitigation was in place. After mitigating, drop the page cache to force a reload from disk:
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"This is containment, not remediation. Dropping the cache evicts a poisoned copy, but if an attacker already reached root, eviction does not remove persistence they established afterward. If you suspect a host was compromised, treat it as compromised and rebuild.
There are three release streams, plus a separate path for CloudLinux for Ubuntu 22.04. Use the one that applies to your CloudLinux version. As patches land, this article will be updated in place. Check the timestamps on the callouts in each stream below.
Status as of June 26, 2026, 13:00 UTC
Patched CloudLinux kernels for CL7h and CL8 are released to the beta channel and rolling out to stable. Target versions:
kernel-4.18.0-553.137.1.lve.el7h or newerkernel-4.18.0-553.137.1.lve.el8 or newerBoth are CloudLinux rebuilds of the upstream fix.
Because the stable rollout is gradual, use the beta channel if you want to install immediately.
Instructions for updating CL8 from the beta channel — cloudlinux-updates-testing:
yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
reboot
uname -rInstructions for updating CL7h from the beta channel — cl7h_beta:
yum --enablerepo=cl7h_beta update 'kernel*'
reboot
uname -rOnce the kernel reaches the stable channel for your server, a plain update will pull the patched version, no extra repo enablement needed:
yum update 'kernel*'
reboot
uname -rStatus as of June 26, 2026, 13:00 UTC
Patched AlmaLinux kernels for CL9 and CL10 are available in the production (stable) repositories. Target versions:
kernel-5.14.0-687.17.1.el9_8 or newerkernel-6.12.0-211.26.1.el10_2 or newerCloudLinux 9 and CloudLinux 10 use the AlmaLinux kernel directly. The patched kernel is already in the production repositories, so a plain update pulls it:
dnf update 'kernel*'
reboot
uname -rUpdate: July 2, 2026, 15:00 UTC
KernelCare livepatches for pedit COW have shipped and are live on the KernelCare main feed for affected CloudLinux versions. KernelCare-subscribed servers receive the fix automatically on the next kcarectl –update. Confirmed patch IDs by version:
K20260624_18 — production feed since June 25K20260626_30 — production feed since June 29K20260625_20 — production feed since June 26K20260625_01 — production feed since June 25Status as of June 26, 2026, 13:00 UTC
KernelCare livepatches for CVE-2026-46331 are in active build and test. Per-distro release status will be appended here as patches roll out to the testing and main feeds.
The KernelCare livepatch for pedit COW is a full port of the upstream fix and is live on the production feed. KernelCare-subscribed systems receive it automatically on the next update:
kcarectl --updateNot using KernelCare yet? You can roll the fix out across your entire fleet automatically, without reboots. Get started in a few minutes — more information here.
CloudLinux for Ubuntu 22.04 runs the stock Ubuntu kernel; there is no CloudLinux-built kernel for this platform, and the production fix arrives from Canonical via apt. Track its status on the Ubuntu CVE page. While the Canonical kernel fix is pending, the KernelCare for Ubuntu livepatch (Stream 3, patch K20260625_01) is now live and is the recommended rebootless remediation in the meantime.
After update + reboot:
uname -rCompare to the target version for your CloudLinux stream above.
For KernelCare:
kcarectl --info | grep kpatch-build-timeA build time on or after the livepatch publish date includes the pedit COW fix. Alternatively, once patch metadata is finalized:
kcarectl --patch-info | grep CVE-2026-46331
Comments