DELine - Dirty Frag (CVE-2026-43284, CVE-2026-43500): Linux Kernel Privilege Escalation Impact, Fixes and Mitigation

Correction (2026-11-02): the first version of this article had the wrong CVE number, fixed versions, mechanism and mitigations. Its claim that kernels 6.6.8, 6.5.20 and 5.15.146 are fixed was wrong, and filtering fragmented packets or disabling RAW sockets is not an effective mitigation. If you relied on that version to judge a system safe, please check it again against the details below.

Dirty Frag is a pair of Linux kernel local privilege escalation vulnerabilities disclosed in May 2026: CVE-2026-43284 (IPsec ESP) and CVE-2026-43500 (RxRPC). An attacker who can run code on a machine as an ordinary user can use them to become root, and exploit code is public. The fix is to upgrade to a patched kernel. If you can’t upgrade yet, you can block the affected kernel modules in the meantime. This article is current as of 2026-11-02 and is based on the CVE records and vendor advisories.

Key points

Remote packets alone can’t trigger it: the attacker must first be able to run code on the machine, but a low-privilege account or limited code execution is enough.
Exploitation is reliable: the researcher describes it as a deterministic logic bug that needs no race condition and does not panic the kernel when an attempt fails.
The Copy Fail mitigation doesn’t stop it: blocking the algif_aead module has no effect on Dirty Frag.
Fix the Fragnesia variant as well: CVE-2026-46300 has later fixed versions, and CISA added it to its Known Exploited Vulnerabilities catalog on 2026-10-28. Your upgrade target should cover it too.

What the flaw is

The “Frag” in the name refers to the paged fragments of the kernel’s sk_buff network buffer, not to IP fragmentation. Before decrypting a packet in place, the kernel should make sure those pages belong privately to the packet. Both flaws get around that check:

CVE-2026-43284: pages spliced into UDP packets were not marked as shared, so ESP input took its no-copy fast path and decrypted directly on top of them.
CVE-2026-43500: when handling DATA and RESPONSE packets, RxRPC made a private copy only if the packet was cloned, so it could also decrypt in place over shared pages.

The result is that an attacker can modify data in the page cache, including the cached contents of privileged files, and gain root. The kernel.org CVE team scores CVE-2026-43284 at CVSS 8.8, while CISA and Red Hat score it at 7.8. All three score CVE-2026-43500 at 7.8. Red Hat rates both as Important.

What exploitation requires

Vulnerability	Requirement	Where it doesn’t work
CVE-2026-43284 (ESP)	`CAP_NET_ADMIN`, which an unprivileged user can get inside a new user and network namespace	Systems that block unprivileged namespace creation, such as Ubuntu with its AppArmor policy
CVE-2026-43500 (RxRPC)	The ability to create an RxRPC socket, with no administrative privileges	Systems without the `rxrpc` module. The researcher says most distributions don’t include it, but Ubuntu loads it by default

Each flaw covers the other’s gaps, so the researcher chained them and tested specific releases of Ubuntu, RHEL, Fedora, openSUSE, CentOS Stream and AlmaLinux.

Fixed versions

These are upstream kernel versions. Distributions usually backport patches to their own kernels, so their version numbers can’t be compared directly. Go by your distribution’s advisory.

Vulnerability	Affected since	Upstream fixed versions
CVE-2026-43284 (ESP)	4.11	5.10.255, 5.15.205, 6.1.171, 6.6.138, 6.12.87, 6.18.28, 7.0.5, 7.1
CVE-2026-43500 (RxRPC)	5.3 (CVE record)	6.6.140, 6.12.88, 6.18.29, 7.0.6, 7.1
CVE-2026-46300 (Fragnesia)	3.9	5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33, 7.0.10, 7.1

Two things to note. For CVE-2026-43500, the researcher’s write-up gives a June 2023 commit as the starting point, which doesn’t match the 5.3 in the CVE record. Its CVE record also lists no fixed versions for the 5.10, 5.15 and 6.1 branches, so check your distribution’s advisory for those.

Status by distribution and platform

Red Hat: RHEL 8, 9 and 10 and products built on their kernels are affected by CVE-2026-43284 and CVE-2026-46300, but not by CVE-2026-43500. Advisory RHSB-2026-003 is marked resolved and says fixes have been released.
Debian: fixes for both flaws are in DSA-6253-1 (trixie, 6.12.86-1), DSA-6258-1 (bookworm, 6.1.170-3) and DLA-4572-1 (bullseye, 5.10.251-4).
Ubuntu: see Canonical’s post for mitigations and fix status.
OpenShift 4: fixed versions for CVE-2026-43284 include 4.21.15, 4.20.22, 4.19.31, 4.18.41, 4.16.62, 4.14.66 and 4.12.90. Fragnesia has different fixed versions, so check Red Hat’s article.
GKE: Container-Optimized OS doesn’t include rxrpc but is affected through the ESP path, and Ubuntu nodes are affected through both paths. Containers using GKE Sandbox are not affected. See bulletin GCP-2026-030 for fixed versions.

Mitigating if you can’t upgrade yet

Option 1: block the modules. This comes from the researcher. It breaks IPsec, and rxrpc is used by AFS. Check with lsmod first, because modules in use can’t be unloaded.

printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc
echo 3 > /proc/sys/vm/drop_caches

After upgrading the kernel, delete /etc/modprobe.d/dirtyfrag.conf to undo this.

Option 2: disable unprivileged user namespaces. Red Hat offers this for environments that must keep IPsec. Put user.max_user_namespaces=0 in /etc/sysctl.d/dirtyfrag.conf and run sysctl --system. It can affect rootless containers, sandboxed browsers and Flatpak. The RxRPC path doesn’t depend on namespaces, so on systems with the rxrpc module, block that module as well.

Both options are temporary and don’t replace a kernel upgrade. Dirty Frag is triggered by local actions, so filtering fragmented packets at the perimeter or disabling RAW sockets doesn’t solve it.

What to watch in container environments

Containers share the host’s kernel. The kernel.org CVE record says CVE-2026-43284 can be used from a user and network namespace to modify the page cache of privileged host files, escaping the namespace or sandbox to gain root on the host.

Google’s bulletin says containers using the RuntimeDefault seccomp profile can’t call unshare, so the ESP path doesn’t affect them. Containers explicitly granted CAP_NET_ADMIN remain affected. This doesn’t cover the RxRPC path.
Pods with no seccomp profile run as Unconfined on many clusters, so check each one rather than assuming it’s protected.
Google and Red Hat both recommend running workloads as non-root. Red Hat also warns that privileged pods and pods using host namespaces remain a viable attack surface.

How to check your systems

Find the kernel version with uname -r and your package manager, then confirm against your distribution’s advisory that it includes the fixes for all three CVEs.
Run lsmod | grep -E 'esp4|esp6|rxrpc' to see whether the modules are loaded, and confirm whether your workloads depend on IPsec.
Run sysctl user.max_user_namespaces to see whether unprivileged users can create namespaces.
Start with shared hosts, container hosts and CI runners. They run other people’s code, so they have the most low-privilege entry points.
After upgrading, reboot into the new kernel and confirm that uname -r changed. Installing without rebooting leaves the running kernel as it was.

Frequently asked questions

Is Dirty Frag being exploited in the wild?

As of the 2026-10-30 edition of CISA’s Known Exploited Vulnerabilities catalog, neither CVE-2026-43284 nor CVE-2026-43500 is listed, although CISA’s record shows public proof-of-concept code for the former. Not being listed doesn’t mean nobody is exploiting them. The related Copy Fail (CVE-2026-31431) and Fragnesia (CVE-2026-46300) are both listed.

Can a firewall stop it?

No. The CVE record says triggering it takes local actions, and remote packets alone can’t supply the shared pages it needs. A firewall can reduce an attacker’s chances of getting in, but it can’t stop someone already inside from escalating privileges.

Do I still need to act if I’ve patched Copy Fail?

Yes. These are different flaws, and blocking algif_aead doesn’t stop Dirty Frag.

What should I do if I suspect it was exploited?

The researcher warns that exploitation contaminates the page cache, which has to be cleared by dropping caches or rebooting. That only removes the modified cache and doesn’t prove the system wasn’t compromised. We suggest treating it as an intrusion: keep the logs, check for new accounts, scheduled jobs and key use, and rebuild the host and rotate credentials where needed.