DirtyClone (CVE-2026-43503): the Linux kernel flaw that gives root and leaves no trace on disk

Another one from the «Dirty» family

If you've been running Linux servers for a while, the «Dirty» surname means serious trouble. DirtyCOW in 2016, DirtyPipe in 2022… and now, in barely six weeks, three new cousins: Dirty Frag, Fragnesia and the loudest of them, DirtyClone.

On 25 June, JFrog's researchers published the first working exploit for CVE-2026-43503, which they nicknamed DirtyClone. On 1 July, Canonical put out its advisory confirming that every supported Ubuntu release was affected and that patched kernels are already available. We're writing this with the patch freshly applied on the machines we manage, because this one deserves your attention this very week.

In one sentence

When the kernel copies a network packet internally, two helper functions (__pskb_copy_fclone() and skb_shift()) fail to propagate a flag —SKBFL_SHARED_FRAG— that marks the packet's memory as shared with a file on disk (the page cache).

That missing flag is the whole vulnerability. A local user can map the pages of a privileged binary —say /usr/bin/su— into memory, «wire» them into a packet, force the kernel to clone it, and push it through an IPsec tunnel they control. The in-place decryption operation overwrites those pages, and with them the in-memory copy of the binary. It swaps the login checks for bytes of the attacker's choosing.

The result: root. No remote exploit, no classic escalation path, using a binary that was already on the box.

What makes it especially nasty: it leaves no trace

Here's the detail that sets DirtyClone apart from a normal privilege escalation: the file on disk doesn't change by a single byte.

The modification lives only in the copy the kernel keeps in the page cache. The consequences are the ones that keep any forensics person up at night:

• File integrity tools (AIDE, Tripwire, debsums) see nothing: the on-disk hash is correct.
• There are no logs of the change.
• A simple reboot restores the original binary, because the poisoned copy only ever lived in RAM.

In other words: an attacker can get root, do what they need, and when the box reboots the main evidence evaporates on its own. On a multi-tenant or shared-hosting server, this is exactly the kind of flaw you don't want left open one day longer than necessary.

Who it affects

• Affected distributions: the whole family. Canonical confirms every supported Ubuntu; the bug lives in the kernel's networking stack, so Debian, RHEL/AlmaLinux/Rocky and the rest share the root cause.
• Who can exploit it: any local user holding —or able to obtain— the CAP_NET_ADMIN capability. And there's the catch: on many systems that capability is trivially available through unprivileged user namespaces, which are enabled by default.
• Containers: on top of local escalation, the flaw can facilitate container escape where network privileges aren't tightly scoped.
• CVSS 8.8 (high). A public exploit has existed since 25 June. This is not theoretical.

In everyday terms: if you have untrusted SSH users, shared hosting, containers, or any local account you don't fully control, you're inside the risk perimeter.

Patched versions on Ubuntu

These are the kernels at which the flaw is closed, per Canonical's official advisory:

Cloud kernels (AWS, Azure, GCP, Oracle, KVM, Raspberry Pi…) have their own equivalent patched versions. Check yours with uname -r and cross-reference your distro's advisory: don't trust the number alone, look at the package date.

What to do today

No fluff. This is what we rolled out on client machines these past days.

1. Update the kernel and reboot

It's the only definitive fix. And yes, it needs a reboot.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade
sudo reboot

# RHEL / AlmaLinux / Rocky
sudo dnf update kernel
sudo reboot

Before rebooting, confirm grub points to the new kernel (dpkg --list | grep linux-image on Debian/Ubuntu, grubby --default-kernel on the RHEL family). Accidentally rebooting into the old kernel at three in the morning is a classic worth avoiding.

If you have unattended-upgrades on, the patch lands on its own within 24 hours —but the reboot doesn't. Schedule the reboot window yourself.

2. Temporary mitigation while you can't reboot

If the box can't be stopped immediately, cut the path the flaw is exploited through: disable unprivileged user namespaces, which is where the attacker gets the CAP_NET_ADMIN they need.

On Ubuntu 24.04 or later (with AppArmor):

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

On earlier versions:

sudo sysctl -w kernel.unprivileged_userns_clone=0

To make it persist across reboots:

echo "kernel.apparmor_restrict_unprivileged_userns=1" | sudo tee /etc/sysctl.d/99-cve-2026-43503.conf

Careful: this closes the most convenient exploitation path, it does not remove the flaw, and it can break containers or tools that rely on unprivileged user namespaces (some rootless Docker/Podman flows, bwrap, etc.). Test it in staging first. It does not get you off the hook for patching.

3. If you have Ubuntu Pro, check Livepatch

For servers whose reboot window is far off, check whether the patch is available via Livepatch (pro status / canonical-livepatch status). It applies the fix live without a reboot, as a bridge until your next planned maintenance.

4. Audit — with one important caveat

Review the usual suspects —/var/log/auth.log, journalctl, auditd for ptrace/namespace-creation calls— but assume this flaw barely leaves footprints. Since the on-disk binary doesn't change and a reboot wipes the poisoned copy, the absence of evidence doesn't prove you weren't touched. If the server has untrusted local users and had gone days unpatched, treat it as potentially compromised: rotate credentials and keys.

What we did these past days

At Atenea Systems the order was the usual one when one of these drops:

1. Servers with external users first: shared hosting, client jails, boxes with SFTP and third-party local accounts.
2. Container hosts: because of the added escape risk.
3. Single-admin dedicated VPS: smaller local surface, they come last.

Where the reboot window hadn't arrived yet, we left the user-namespace restriction on as a stopgap. As of today every machine we manage is on a patched kernel or mitigated while it waits for its scheduled reboot.

What we take away

DirtyClone isn't a remote flaw anyone can fire off from the internet: it needs a local account. But it's exactly the kind of escalation that turns «an annoying user» into «root on your server» — and does it without leaving the trail that normally warns you something's wrong.

The recipe, like every time one of these lands, boils down to five moves: check the kernel version, check the last reboot date, update, reboot, verify. A patching plan that actually works isn't a luxury: it's what separates the server that survives a bad Wednesday from the one that doesn't. If yours amounts to «whenever I remember», let's talk.

References

• DirtyClone Linux kernel local privilege escalation vulnerability — fixes available (Canonical)
• Dissecting and Exploiting Linux LPE Variant: DirtyClone (CVE-2026-43503) — JFrog Security Research
• CVE-2026-43503 — Ubuntu Security
• 'DirtyClone' Linux Kernel Vulnerability Leads to Root Access — SecurityWeek