DirtyClone and the Shared-Frag Marker Bug That Keeps Coming Back

The Short Version

Jump to the Long Version ↓

What: DirtyClone, tracked as CVE-2026-43503, is a Linux kernel local privilege escalation in the networking stack: some skb fragment-transfer paths drop the SKBFL_SHARED_FRAG marker that blocks in-place writes, letting ESP (IPsec) input decrypt directly over file-backed page-cache pages. That’s an arbitrary write into root-owned read-only files, Dirty COW via the network stack instead of /proc/self/mem.

Impact: A local unprivileged user turns the marker loss into a page-cache write against a binary like /usr/bin/su, then rides the poisoned image to root. JFrog published an exploit walkthrough on June 25; the public PoC (rafaeldtinoco/security/exploits/dirtyclone, building on Hyunwoo Kim’s DirtyFrag primitive) reproduces on older kernels. The disk file never changes, so file-integrity tools miss it.

Status: DirtyClone belongs to the DirtyFrag/Fragnesia family: a safety marker gets lost as file-backed memory moves through fast networking paths, and a later in-place write lands where it should have copied. JFrog reported it May 19; the fix shipped in v7.1-rc5 on May 24. That makes it an N-day for RHEL fleets missing part of the fix chain, not a fresh 0-day.

Severity: Red Hat rates it Important, CVSS 7.0; kernel.org scores it 8.8, driven by a lower attack-complexity rating and a Changed (vs Unchanged) scope call, but either way the outcome is root. Bug class: a shared-fragment marker propagation failure causing unsafe in-place writes into page-cache-backed memory.

Why this matters: The exposed systems are ones where isolation is the product: multi-tenant hosts, CI runners, container and Kubernetes nodes, and dev sandboxes reachable via CAP_NET_ADMIN, which many distros grant unprivileged users inside a namespace by default. “Local” does not mean “low risk” here.

Do this now: The fix is already on the EL9 and EL10 feeds, so update and reboot. If you cannot patch yet, disable unprivileged user namespaces or block esp4/esp6 autoload where IPsec is unused. KernelCare users already have a rebootless patch for affected EL9/EL10 kernels. Details below.

Some of the most serious Linux kernel bugs do not start life as an obvious “write to root files” vulnerability. They start as bookkeeping mistakes. DirtyClone is one of those. A missing ownership marker on socket-buffer fragments gets trusted by a later network operation, which then writes straight through.

The Linux networking stack moves packet data in socket buffers, or skbs. Some of that data lives as page fragments rather than being copied byte-for-byte into private memory. That is good for performance and unforgiving about ownership, because a fragment can point at a page that is shared, externally owned, or backed by the page cache. Before any code writes into such a page, it needs to know the page is not safe to touch in place.

That is the entire job of SKBFL_SHARED_FRAG. The marker tells later packet-processing code that an skb holds shared fragments and that in-place mutation is off-limits unless the kernel first copies the data into private memory. DirtyClone happens when that marker goes missing while fragments move from one skb to another. NVD names __pskb_copy_fclone() and skb_shift() among the helpers that can move frag descriptors without carrying the marker across, leaving the destination skb with page-cache-backed references while skb_has_shared_frag() returns false.

That false answer is the vulnerability. A later in-place writer looks at the skb, asks whether the fragments are shared, hears no, and writes directly into the underlying page. ESP input in esp4.c is exactly that kind of writer, and it is the sink the public exploit drives.

DirtyClone rounds out a cluster of these bugs that arrived across the spring, each with the same failure mode. File-backed page-cache memory gets treated as ordinary packet data, then an in-place network operation writes where it should have copied. Copy Fail came first in late April. DirtyFrag followed on May 7. Fragnesia bypassed the DirtyFrag patch on May 13. DirtyClone is the fourth, reached through yet another packet-cloning path that drops the same one-bit marker.

Here is the part that should shape how you triage it. DirtyClone is not a fresh 0-day burning through fully-patched fleets. What JFrog published on June 25 is a demonstration that residual code paths left open by a partial patch are still reachable. The operative word is complete. A kernel is only protected once it carries the whole DirtyFrag and Fragnesia chain. One that took the original DirtyFrag fix but missed the follow-ups still has a reachable path to the same ESP sink. Red Hat’s current EL9 and EL10 kernels already carry the full backport, which is why the danger sits with the kernels that are a few updates behind rather than with current ones.

How DirtyClone Works

The public chain runs from an unprivileged socket configuration to an arbitrary write into privileged page cache.

[Unprivileged user + network namespace]
│  attacker obtains CAP_NET_ADMIN inside the namespace
▼
[netfilter TEE rule clones ESP-in-UDP packets]
│  clone routed through __pskb_copy_fclone(), marker dropped
▼
[Mislabelled skb: references page-cache pages,
reports skb_has_shared_frag() == false]
▼
[XFRM ESP transport SA decrypts in place]
│  esp_input() AES-CBC writes over the target file's page cache
▼
[Arbitrary content in root-owned page cache]
│  overwrite /usr/bin/su (or /etc/sudoers.d/* via an NSS load)
▼
[uid=0 root shell]

The marker. The kernel tags any skb holding page references it does not own with SKBFL_SHARED_FRAG, and skb_has_shared_frag() reads that tag to decide whether a payload can be mutated in place. When a frag-transfer helper moves paged fragments between skbs without carrying the marker over, the destination skb keeps references to externally owned or page-cache-backed pages while reporting that nothing is shared.

The sink. A later in-place writer trusts that report. In DirtyClone’s case the writer is esp_input() AES-CBC decryption, which decrypts directly over those pages, including the page cache of root-owned, read-only files. With control of the ESP key and security association plus the spliced source pages, the attacker turns this into an arbitrary-content write into privileged page cache.

The route. Red Hat attributes the EL9 and EL10 exposure to skb_try_coalesce() losing the marker (Bugzilla 2480902), and notes the same loss can occur across a family of helpers including __pskb_copy_fclone(), skb_shift(), skb_gro_receive(), and skb_segment(). The public PoC reaches the identical ESP sink by a different door. It runs inside an unprivileged user and network namespace, installs a netfilter TEE rule that clones ESP-in-UDP packets through __pskb_copy_fclone(), which drops the marker, then installs XFRM ESP transport SAs so the cloned, mislabelled packet is decrypted in place over the target file’s page cache.

The important thing is that this is not editing /usr/bin/su on disk in the normal sense. It corrupts the in-memory page-cache copy the kernel later serves to a privileged execution path. That is what makes conventional file-integrity monitoring a weak control here. The file on disk is untouched, the modification lives in the kernel’s in-memory copy, and a reboot restores the original binary, usually well after the attacker already has root.

One detail matters for scope. The PoC’s README names a narrow mainline v7.1-rc1 to rc4 window, but in-house testing reproduces it unmodified on the EL9 and EL10 backported kernels. That upstream window does not bound the impact on RHEL-family distros. Do not read the README’s version range and conclude your EL box is out of scope.

What the Upstream Fix Changes

The fix is small, which is exactly why the family keeps producing variants. It makes the frag-transfer helpers propagate the shared-frag marker, so a destination skb that still references page-cache-backed or externally owned pages reports skb_has_shared_frag() as true. The later in-place writer then refuses to mutate those pages and falls back to a safe copy. The fix landed upstream on May 21 and shipped in Linux v7.1-rc5 on May 24, as part of the same series that closed the earlier DirtyFrag bugs. Stable and backport commit IDs vary by branch, so match your distro’s advisory rather than any single upstream hash.

Who Is Affected

For general Linux users, assume risk if the running kernel lacks the complete DirtyFrag, Fragnesia, and DirtyClone fix chain and the system lets untrusted local code reach the networking capabilities the exploit needs. Public reporting identifies Debian, Fedora, and Ubuntu among the distributions where unprivileged user namespaces make exploitation more reachable under common configurations. Ubuntu 24.04 and later add AppArmor restrictions that can block the default exploit route, but that is hardening around one path, not proof the underlying kernel is fixed.

For RHEL-family systems the picture is narrower, and it comes down to two questions. Is the kernel behind the DirtyFrag and Fragnesia errata, and is the host running a rebootless patch?

Exploitable, reproduced in-house on kernels missing the full chain:

• EL9 on 5.14.0-611.49.2.el9_7, overwrites /usr/bin/su and yields uid=0.
• EL10 on 6.12.0-55.27.1.el10_0, same result.

Not vulnerable:

• Current stock kernels that already carry the complete DirtyFrag and Fragnesia fix, for example EL10 6.12.0-211.16.1.el10_2, where the PoC does not reproduce.
• Any host protected by the rebootless patch on the esp4 module.

Not affected for CVE-2026-43503:

• RHEL 6, 7, and 8. Red Hat marks these not affected for this specific CVE. Read that narrowly. Affected-stream lists differ across the DirtyFrag family, so a stream that is clear for CVE-2026-43503 is not necessarily clear for every related CVE.

Red Hat lists RHEL 9 and RHEL 10, plus OpenShift RHCOS, as affected streams for CVE-2026-43503. That flags the affected code stream, not a fully-updated host. Read “affected” as “this code shipped here,” not “every current RHEL 9 or 10 box is exploitable today.”

Coverage timing also varies by distro and kernel line. CloudLinux (CL8 and CL9) in particular can lag the EL feeds for this family, so CL users should confirm their exact line rather than assume parity.

One caution that applies to the whole family. A host that simply fails the PoC’s assumptions is not the same as a host that is fixed. Confirm the kernel carries the complete errata rather than assuming a failed exploit run means you are safe.

Mitigate Now

The durable fix is a patched kernel or a rebootless patch. Until that is everywhere, the useful controls are the ones that remove the exploit prerequisites.

1. Patch or apply a rebootless patch first

Install your distribution’s fixed kernel and reboot into it, or apply a rebootless patch where a reboot is not acceptable. The fix is already on the EL9 and EL10 feeds, so on most hosts this is an update rather than a wait.

2. Restrict unprivileged user namespaces

The chain needs CAP_NET_ADMIN from an unprivileged userns to install the TEE rule and the XFRM SA. Take that away and the public path breaks.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

Blast radius. This breaks rootless Podman and rootless Docker, unshare(1), Chromium’s sandbox, some CI sandboxes, and bwrap Flatpaks. Acceptable on most locked-down server fleets, disruptive on container and developer hosts. Test before a broad rollout.

3. Block ESP module autoload where IPsec is not used

No esp4 or esp6, no in-place decryption sink for the DirtyClone path.

echo -e 'install esp4 /bin/false\ninstall esp6 /bin/false' | sudo tee /etc/modprobe.d/dirtyclone-esp.conf

Do not apply this on hosts that use IPsec or XFRM, because it disables ESP transport and will break your tunnels. One note for the wider family: the earlier DirtyFrag work also implicated rxrpc as an in-place-write sink, so hardening against the whole family can mean blocking rxrpc too. That one breaks AFS and other RxRPC-dependent workloads, so scope it carefully and only where those features are unused. Revert any mitigation by removing the drop-in files and reloading.

sudo rm -f /etc/modprobe.d/dirtyclone-esp.conf /etc/sysctl.d/99-dirtyclone.conf
sudo sysctl --system

Decision moment. If the host runs no IPsec and no rootless containers, either lever works and the ESP module block is the narrower change. If it needs IPsec but not rootless containers, disable unprivileged userns. If it needs both IPsec and rootless containers, a rebootless patch or a fixed kernel is the only answer that does not break a workload, and you should isolate untrusted local execution until one is in place.

Rebootless Patching

This is the kind of bug rebootless patching solutions, like KernelCare, exist for. Rebooting a fleet into a fixed kernel is easy to say and hard to schedule, and non-disruptive patching closes the same gap without touching uptime.

On the affected EL9 and EL10 kernels it lands on the esp4 module and shuts the ESP-input decrypt sink at the exact point the unsafe write would occur. When the shared-fragment marker is missing because of the propagation bug, in-place decryption over page-cache-backed fragments is refused rather than performed. Same guarantee as the upstream marker fix, just delivered without anyone touching a maintenance window.

Because DirtyClone and CVE-2026-46300 share one root bug and one fix, a single rebootless patch covers both. Worth knowing when you go to verify coverage: in some tooling the protection shows up under the sibling CVE-2026-46300 rather than CVE-2026-43503, since the CVE label can lag the fix itself.

The value here is narrow but real, and it is exactly the case rebootless patching is good at. The hosts most at risk are the ones lagging on kernel updates, and those are precisely the hosts where an emergency reboot is hardest to schedule in the first place. Being able to close DirtyClone on them without that reboot is the difference between fixing it today and fixing it at the next maintenance window, and for a lot of fleets that gap is where the real risk lives.

Detection

There is no reliable on-disk signature for DirtyClone, and that is a core part of the risk. The corruption lives in the page cache, the on-disk binary is untouched, and cache eviction or a reboot restores the original bytes. That does not undo any persistence, account changes, or follow-on activity after the attacker gained root. File hashing is a weak control here.

It may leave no obvious file-integrity evidence, but it is not invisible. Detection is more likely to come from behavioral telemetry, and each of the following is a lead rather than proof:

• Unexpected esp4 or esp6 module loads on hosts that do not run IPsec.
• Unprivileged user-namespace creation followed shortly by XFRM SA installation or a netfilter TEE rule insertion.
• Unusual nft, iptables, XFRM, or TEE activity originating from local user contexts.
• Execution of a setuid binary such as su or sudo immediately after that networking setup, by a user with no reason to touch either.
• A sudden absence of expected security-audit events on a host that should be producing them.

If untrusted or semi-trusted local code ran on an exposed EL9 or EL10 host during the window, prioritize patching and treat the host as warranting a closer look, rather than reading the absence of disk evidence as the absence of compromise.

Why This One Matters

DirtyClone is not remote code execution, and it does not mean an unauthenticated internet user can root every Linux server. For the environments this bug actually lands in, that distinction is cold comfort. CI runners run other people’s code. Shared hosting platforms run customer code. Kubernetes nodes run containers with varying trust levels. Developer sandboxes and build hosts often allow exactly the namespace behavior that makes this class reachable. In each of those, a local privilege escalation is the boundary-crossing event. It turns code that ran where it was allowed into code that became root where it was never supposed to.

The reason DirtyClone is lower-urgency than the headlines suggest is also the reason it is easy to get wrong. A kernel carrying the complete DirtyFrag and Fragnesia chain is protected. But complete is the operative word. A kernel that took the original DirtyFrag patch and then stopped still has a reachable path, and so does any host lagging on distro backports. The risk concentrates in the boxes that skipped the last maintenance window, the long-lived CI runners nobody reboots, and the servers set aside for next quarter. Those are exactly the hosts where an N-day like this quietly becomes a same-day problem. A scanner-only workflow that keys off the affected kernel stream without checking the full fix chain can either cry wolf on patched hosts or miss the ones that are still exposed.

Prioritized Remediation Checklist

1. Patch or apply a rebootless patch to EL9 and EL10 systems that are behind on kernel updates first, especially container hosts, CI runners, shared systems, and multi-tenant environments.
2. Confirm the running kernel carries the complete DirtyFrag, Fragnesia, and DirtyClone fix chain, rather than inferring safety from a failed exploit run.
3. Treat a partial DirtyFrag fix as still vulnerable. Only the full chain closes the path.
4. When verifying rebootless-patch coverage, expect the protection to appear under CVE-2026-46300 in some tooling until the CVE-2026-43503 mapping propagates.
5. CloudLinux CL8 and CL9 can lag the EL feeds for this family, so confirm your exact line.
6. Disable unprivileged user namespaces where the workload can tolerate it.
7. Block esp4 and esp6 autoload where IPsec is unused, and rxrpc too if you are hardening against the wider family and do not use AFS or RxRPC.
8. Hunt for unusual namespace, XFRM, ESP, TEE, nft, su, and sudo activity during the exposure window, and treat clean file hashes as insufficient evidence.

Patch every kernel, no reboot required. If you are not yet a KernelCare user, now is a good time to see how rebootless patching protects critical Linux systems without emergency maintenance windows or downtime.

Get KernelCare today →

References

• Red Hat CVE-2026-43503, Important, CVSS 7.0, RHEL 9 and 10 Affected, RHEL 6/7/8 not affected; Bugzilla 2480902
• Red Hat security-data JSON, CVE-2026-43503
• NVD CVE-2026-43503 (kernel.org CNA score 8.8, Scope Changed)
• Debian Security Tracker, CVE-2026-43503
• Sibling CVE-2026-46300 (Bugzilla 2477015), same root bug via skb_try_coalesce, shares the fix
• JFrog Security Research, “Dissecting and Exploiting Linux LPE Variant: DirtyClone (CVE-2026-43503)”
• SecurityWeek, DirtyClone Linux Kernel Vulnerability Leads to Root Access
• The Hacker News, New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets
• Public PoC, rafaeldtinoco/security/exploits/dirtyclone (JFrog; Hyunwoo Kim DirtyFrag ESP primitive)
• Mainline fix in Linux v7.1-rc5