pedit COW & DirtyClone: Two Critical Linux Kernel Flaws in 2026
Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.
Unsure which of your servers these kernel flaws affect? We detect and prioritise CVEs across your estate and patch within an SLA - see CVE monitoring and Managed Operations, or book an initial consultation.
Within a few weeks in 2026, two Linux kernel local privilege-escalation flaws were published that work the same way: CVE-2026-46331 (nicknamed "pedit COW") and CVE-2026-43503 (named "DirtyClone" by its finders). Both let a low-privileged local user become root by corrupting the page cache. And both are especially dangerous where unprivileged user namespaces are enabled: on container and multi-tenant hosts, in Proxmox LXC environments and in Kubernetes.
This article frames both flaws cleanly (as of June 2026), shows who is affected and how to patch - and which immediate mitigations bridge the time until your maintenance window.
Table of contents
- What happened: two kernel LPEs in one wave
- CVE-2026-46331: pedit COW in detail
- CVE-2026-43503: DirtyClone in detail
- The shared danger: page cache poisoning and container escape
- Check exposure and patch
- Immediate mitigation without a long maintenance window
- How we work at WZ-IT
- Further guides
What happened: two kernel LPEs in one wave
Both flaws are local privilege escalation (LPE): not an attack from the internet, but the step from a plain user (or a compromised service, or a container) to full root. It is exactly this step that turns a small breach into a full system takeover.
- CVE-2026-46331 - "pedit COW" lives in the
act_pedittraffic-control action of thenet/schedkernel subsystem. Published via the Linux CNA at NVD/MITRE on 16 June 2026 (Red Hat first published 18 May 2026). - CVE-2026-43503 - "DirtyClone" lives in the helpers that transfer skb fragments in the ESP/XFRM input path. Published on 23 May 2026, named "DirtyClone" by JFrog's security team.
The closeness to the "Dirty" family is no accident: like Dirty COW (2016) and DirtyPipe (2022), both are at heart page-cache write primitives. But they are separate, new vulnerabilities in different subsystems - not aliases and not a return of the old CVEs.
CVE-2026-46331: pedit COW in detail
act_pedit is the Linux traffic-control packet editor: it writes specific bytes into passing network packets. The bug is in a partial copy-on-write calculation: the writable range of the socket buffer (skb) is computed without the runtime offset that so-called typed keys add. The result is an out-of-bounds write (CWE-787, aided by an integer overflow, CWE-190) into a shared memory page - corrupting the page cache.
In practice this yields root by poisoning the cached copy of a setuid-root binary such as /bin/su - the same approach as DirtyPipe. The bug was introduced in kernel 5.18. It is rated CVSS 7.8 (HIGH) by the kernel.org CNA and NVD (vector AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H); Red Hat lists 6.7 (Important), because it assumes CAP_NET_ADMIN as a prerequisite. That capability is reachable on many systems via unprivileged user namespaces - which explains the lower barrier in the kernel.org score.
CVE-2026-43503: DirtyClone in detail
In DirtyClone, two helper functions fail to propagate the SKBFL_SHARED_FRAG bit when moving fragments between socket buffers (for example during fclone packet cloning in the ESP/XFRM input path). As a result, file-backed page-cache pages are treated as writable packet data - the kernel writes into pages that actually back read-only, root-owned files (CWE-664).
The result is privilege escalation to root with a possible container escape. DirtyClone is rated CVSS 8.8 (HIGH) by the kernel.org CNA - with the important detail S:C (Scope Changed), reflecting the container break-out; Red Hat lists 7.0. The bug has existed since roughly kernel 3.9 and was fixed in mainline on 21 May 2026 (first release tag v7.1-rc5). Details in the NVD record.
The shared danger: page cache poisoning and container escape
At their core, both flaws are the same tool: a write into the page cache where it does not belong. Anyone who can write into the cached copy of a read-only, root-owned file can rewrite a setuid binary and gain root - the proven DirtyPipe attack path.
The real multiplier is unprivileged user namespaces. They grant a normal user capabilities such as CAP_NET_ADMIN inside their own namespace, and thus access to the vulnerable paths. On shared hosts this weighs double: containers (LXC, Docker, Kubernetes) share one kernel with the host. A kernel LPE there potentially means escaping the container and taking over the entire host - including all neighbouring tenants. For operators of Proxmox LXC hosts and Kubernetes clusters, this is why these two CVEs sit at the top of the patch list.
Check exposure and patch
Affected is essentially every current distribution running a vulnerable kernel - pedit COW from 5.18, DirtyClone from around 3.9, each up to the fixed version. The status of the major distributions (as of June 2026):
- CVE-2026-46331 (pedit COW): fixed in RHEL 8/9/10 (RHEL 6/7 not affected), in the Ubuntu LTS kernels and in Debian 13, plus mainline/stable. Vendor status: Ubuntu, Red Hat.
- CVE-2026-43503 (DirtyClone): fixed in mainline on 21 May 2026 (v7.1-rc5), with backports for Ubuntu (24.04/22.04 and others), Debian (bullseye/bookworm/trixie) and RHEL 9/10. Vendor status: Ubuntu, Debian.
Concretely: determine the running kernel with uname -r, compare it against the version your distribution marks as fixed, update the kernel package and reboot (or apply a live patch). On a larger fleet this is exactly the sticking point - knowing which hosts even run a vulnerable kernel. Doing that inventory in hours rather than days is the job of continuous CVE monitoring.
Immediate mitigation without a long maintenance window
If an immediate reboot is not possible, two measures lower the risk significantly - as a bridge, not a replacement for the patch:
- Disable unprivileged user namespaces. On Debian/Ubuntu:
sysctl -w kernel.unprivileged_userns_clone=0. This closes the main path a normal user uses to reach both flaws. Caution: some container runtimes need user namespaces - test first. - Blocklist the
act_peditmodule (against pedit COW). If you do not usetc pedit, you can prevent the module from loading via a blocklist and remove the vulnerable path entirely.
In addition, the usual applies: who may run containers or obtain CAP_NET_ADMIN should be tightly limited. These settings belong in a hardened baseline - you can check the current state with a security audit.
How we work at WZ-IT
We treat kernel CVEs as part of operations, not as one-off firefighting - within Managed Operations:
- Detect and prioritise. CVE monitoring matches new CVEs against the real estate and prioritises by CVSS and reachability - a local-only LPE on an isolated host is different from the same flaw on a multi-tenant LXC host.
- Patch within an SLA. Kernel updates are tested, rolled out in maintenance windows and activated via reboot or live patch - with defined response times instead of "eventually".
- Harden. Hardened baselines (disabled unprivileged user namespaces where possible, a minimal set of modules, limited
CAP_NET_ADMIN) reduce the attack surface for good - especially on Proxmox container hosts.
That turns "two new kernel CVEs" into a controlled routine rather than a night shift.
Further guides
- Linux kernel vulnerabilities 2026: patch management at board level - the strategic frame around kernel updates.
- CVE monitoring for self-hosted software - how continuous vulnerability monitoring works in the enterprise.
- OPNsense 26.1.8: CVE-2026-44194/45158 and patch management - the same principle on the firewall.
- CVE monitoring hub - our approach to continuous vulnerability detection and patching.
Before the next kernel flaw lands: we monitor your systems for CVEs, prioritise by real risk and patch within an SLA. Book an initial consultation now.
Sources
Frequently Asked Questions
Answers to important questions about this topic
Most likely, if you run a current Linux server with an unpatched kernel. CVE-2026-46331 affects kernels from version 5.18, CVE-2026-43503 even kernels from around 3.9. Both are patched in current distributions (RHEL 8/9/10, Ubuntu, Debian). Check the running kernel version (uname -r) against the version your distribution marks as fixed.
No. Both are local privilege escalation (LPE) flaws: an attacker already needs low-privileged access on the system. The danger is that unprivileged user namespaces open the path to the vulnerable code for a normal user - which is exactly the default situation on container and multi-tenant hosts.
They share the pattern, not the bug. Dirty COW (CVE-2016-5195) and DirtyPipe (CVE-2022-0847) were also page-cache write primitives. pedit COW and DirtyClone are separate, new CVEs in different kernel subsystems (net/sched and the skb fragment transfer), but they reuse the same exploit idea: overwriting a read-only, root-owned file in the page cache.
Containers (LXC, Docker, Kubernetes) share a single kernel with the host. A kernel LPE can therefore lead to a container escape and full host takeover. CVE-2026-43503 (DirtyClone) is explicitly described with a possible container escape. For Proxmox LXC and Kubernetes hosts, patching is therefore high priority.
Updating the kernel package closes the flaw, but the new kernel only becomes active after a reboot - or via live patching (kpatch/Ksplice/kGraft) if in use. Until the maintenance window, both flaws can be significantly mitigated by disabling unprivileged user namespaces.
High. CVE-2026-43503 is rated CVSS 8.8 (kernel.org), CVE-2026-46331 7.8; a public exploit pattern exists for pedit COW. Both lead to root. On shared or container hosts they belong in the next regular patch window, not in the backlog.
Written by
Timo Wevelsiep
Co-Founder & CEO
Co-Founder of WZ-IT. Specialized in cloud infrastructure, open-source platforms and managed services for SMEs and enterprise clients worldwide.
LinkedInLet's Talk About Your Idea
Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.
Leading companies trust WZ-IT
Timo Wevelsiep & Robin Zins
Managing Directors of WZ-IT