Dirty Frag is a vulnerability (class) that achieves root privileges on most Linux distributions by chaining the xfrm-ESP Page-Cache Write vulnerability and the RxRPC Page-Cache Write vulnerability.
Find a file
Clem 44af5b1a14
Add Kubernetes mitigation manifest
Adds a self-contained DaemonSet manifest under k8s/ that applies the
mitigation from the README (modprobe blacklist of esp4/esp6/rxrpc +
page-cache flush) to every Linux node in a Kubernetes cluster, and
re-applies it automatically on any new node that joins the cluster
(autoscaling, node-image upgrade, scale-set rolling update).

  - k8s/dirtyfrag-mitigation.yaml — single-file manifest applyable with
    kubectl apply -f. Uses an init container that nsenter's into PID 1
    to write /etc/modprobe.d/disable-dirtyfrag.conf, modprobe -r each
    module that has refcnt=0, and echo 3 > /proc/sys/vm/drop_caches.
    For any module that remains loaded with refcnt > 0, emits a single
    aggregated Warning Kubernetes Event on the Node (no auto-cordon).
    A long-running pause container keeps the pod Running so the init
    container is only re-executed on pod recreation.
  - k8s/README.md — apply / verify / revert instructions and
    compatibility notes (esp4/esp6 = IPsec, rxrpc = AFS).
  - README.md — short Kubernetes section in Mitigation pointing to k8s/.

Tested on AKS (Azure) running Kubernetes 1.30, in a production
environment across staging and production clusters.
2026-05-08 10:41:03 +02:00
assets typo 2026-05-08 05:22:07 +09:00
k8s Add Kubernetes mitigation manifest 2026-05-08 10:41:03 +02:00
exp.c typo 2026-05-08 03:46:07 +09:00
README.md Add Kubernetes mitigation manifest 2026-05-08 10:41:03 +02:00

Dirty Frag: Universal Linux LPE

tux

Abstract

tux

This document describes the Dirty Frag vulnerability class, first discovered and reported by Hyunwoo Kim (@v4bel), which can obtain root privileges on major Linux distributions by chaining the xfrm-ESP Page-Cache Write vulnerability and the RxRPC Page-Cache Write vulnerability.

Dirty Frag is a case that extends the bug class to which Dirty Pipe and Copy Fail belong. Because it is a deterministic logic bug that does not depend on a timing window, no race condition is required, the kernel does not panic when the exploit fails, and the success rate is very high.

For detailed technical information and the timeline, see here.

Because the embargo has currently been broken, no patch or CVE exists. After consultation with the maintainers on linux-distros@vs.openwall.org and at their request, this Dirty Frag document is being published. For the disclosure timeline, refer to the technical details.

Exploiting

One-line special

git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

This PoC is provided as accurate information following consultation with linux-distros. Do not use it on systems that you are not authorized to test.

⚠️ Important: After running this exploit, the page cache is contaminated. To clear the polluted page cache and ensure system stability, either run:

echo 3 > /proc/sys/vm/drop_caches

or reboot the system.

Affected Versions

The xfrm-ESP Page-Cache Write vulnerability is in scope from cac2661c53f3 (2017-01-17) up to upstream, and the RxRPC Page-Cache Write vulnerability is in scope from 2dc334f1a63a (2023-06) up to upstream.

In other words, the effective lifetime of the vulnerabilities is about 9 years.

This Dirty Frag has been tested on the following distribution versions.

  • Ubuntu 24.04.4: 6.17.0-23-generic
  • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
  • openSUSE Tumbleweed: 7.0.2-1-default
  • CentOS Stream 10: 6.12.0-224.el10.x86_64
  • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
  • Fedora 44: 6.19.14-300.fc44.x86_64
  • ...

Mitigation

  1. Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. Use the following command to remove the modules in which the vulnerabilities occur and clear the page cache.
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
  1. Once each distribution backports a patch, update accordingly.

Kubernetes

For Kubernetes clusters, k8s/dirtyfrag-mitigation.yaml deploys a DaemonSet that applies the same mitigation on every Linux node and re-applies it automatically on any new node that joins the cluster. See k8s/README.md for details, compatibility notes, and the revert procedure.

kubectl apply -f https://raw.githubusercontent.com/V4bel/dirtyfrag/master/k8s/dirtyfrag-mitigation.yaml

FAQ

Why did you chain two vulnerabilities?

xfrm-ESP Page-Cache Write provides a powerful arbitrary 4-byte STORE primitive like Copy Fail, and is included on most distributions, but it requires the privilege to create a namespace.

Ubuntu sometimes blocks unprivileged user namespace creation through AppArmor policy. In such an environment, xfrm-ESP Page-Cache Write cannot be triggered. RxRPC Page-Cache Write does not require the privilege to create a namespace, but the rxrpc.ko module itself is not included in most distributions. However, on Ubuntu, the rxrpc.ko module is loaded by default.

Chaining the two variants makes the blind spots cover each other, allowing root privileges to be obtained on every major distribution. For details, refer to the technical details document.

Another "branded" "Dirty" series?

Yeah, yeah, I know. However, this vulnerability is a descendant of "Dirty Pipe", and it is a bug class that "dirties" the frag member of struct sk_buff, so this name is the most appropriate.

What is its relationship with the "Copy Fail" vulnerability?

Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is triggered regardless of whether the algif_aead module is available. In other words, even on systems where the publicly known Copy Fail mitigation (algif_aead blacklist) is applied, your Linux is still vulnerable to Dirty Frag.

So, how do I fix my Linux?

Refer to the Mitigation and Disclosure Timeline sections. Due to external factors, the embargo has been broken, so no patch exists for any distribution.