Dirty Frag: what to do before your distro ships a kernel update

A second Linux kernel local privilege escalation chain in the same architectural bug class as Copy Fail dropped on May 7, 2026. Hyunwoo Kim (V4bel) named it "Dirty Frag." Two CVEs apply: CVE-2026-43284 in the IPsec ESP modules (informally called "Copy Fail 2.0") and CVE-2026-43500 in the RxRPC module that AFS depends on. Canonical rates the chain HIGH at CVSS 7.8. Red Hat rates it "Important." Within hours of V4bel's disclosure, an unrelated party reverse-engineered the upstream ESP fix commit and published a separate exploit they called "Copy Fail 2: Electric Boogaloo," which is the same vulnerability as CVE-2026-43284 with a different name attached. As of May 8 afternoon UTC, the exploit code is public, deterministic, and reliable. Three distributions have shipped fixed kernels: Debian (Trixie 6.12.86-1 via DSA-6253-1; unstable 7.0.4-1), AlmaLinux (AL8 4.18.0-553.123.2.el8_10, AL9 5.14.0-611.54.3.el9_7, AL10 6.12.0-124.55.2.el10_1, all in stable repos as of 15:22 UTC), and CloudLinux (CL9/CL10 inherit the AlmaLinux build in stable; CL7h and CL8 are in the beta channel; KernelCare el8 livepatches reached the testing feed at 12:00 UTC). Ubuntu, Red Hat, Fedora, openSUSE, Amazon Linux, Oracle Linux, and Arch had not shipped fixed kernels at the same timestamp.

If you spent the end of April applying the Copy Fail mitigation to your fleet, the most important operational point about Dirty Frag is that your existing mitigation does not cover it. The algif_aead modprobe deny gates one entry to the in-place decryption sink that produces the page-cache-write primitive. Dirty Frag uses two different entries (the IPsec ESP receive path and the RxRPC receive path) that reach the same sink without going through algif_aead. Hosts hardened against Copy Fail are fully exposed to Dirty Frag.

What Dirty Frag is, in one paragraph

The kernel's modern zero-copy I/O stack lets userspace attach pages it owns into a socket buffer using splice(2), sendfile(2), or MSG_SPLICE_PAGES. Several kernel modules perform cryptographic decryption "in-place" on inbound socket-buffer pages for performance, on the assumption that those pages are private to the kernel. When a userspace process has attached its own pages into the path, decryption writes plaintext into a page that the unprivileged process still holds a reference to. The process now has a write primitive into the page cache, and the rest of the exploit is a one-command corruption of the in-memory copy of /usr/bin/su (or any other setuid binary). Copy Fail, disclosed April 29, abused this in algif_aead. Dirty Frag, disclosed May 7, abuses the same architectural mistake in the IPsec ESP receive path and in rxrpc.ko.

Three confirmed instances of the same pattern in nine days is evidence that the pattern is general. The kernel security team and external researchers are auditing the rest of the in-place decryption surface, and additional CVEs in this family across the rest of 2026 are a foreseeable possibility. Operators building remediation playbooks should write them around the bug class rather than around the specific CVE identifier.

Where the exposure actually sits

Dirty Frag is a local privilege escalation. Any Linux host with multi-user access, untrusted code execution, or shared workload tenancy is in the direct blast radius. The classes of host that matter most in customer environments include:

• Kubernetes and OpenShift worker nodes that host pods from more than one tenant. Container isolation primitives do not gate the kernel surface that Dirty Frag exploits. A pod with default capabilities that achieves root on the node has read/write access to every other tenant's page cache for the duration of the patch window.
• Self-hosted CI/CD runners that execute pull-request code from external contributors, and any pipeline that compiles dependencies pulled from registries.
• Build and analytic hosts in shared engineering environments, including JupyterHub deployments, university lab machines, and shared data-science VMs.
• Jump hosts and bastion servers with broad operator populations, particularly in federal and regulated environments where multiple support tiers share one Linux host.
• Agent and sandbox environments that allow LLM-driven shell execution inside a Linux container, where the platform is built on shared-kernel containers rather than Firecracker microVMs (AWS Lambda, Fargate), gVisor, or V8 isolates.

Single-tenant appliance products (PAN-OS firewalls, F5 BIG-IP, traditional load balancers) are not directly in scope. Their threat model excludes unprivileged shell access on the management plane, so the local-attacker prerequisite is not present. The exposure that does matter for those vendors' customers is on the general-purpose Linux estate around the appliance: management workstations, configuration servers, syslog collectors, Panorama hosts, BIG-IQ, NGINX hosts, and so on.

What to do during the patch window

Block the three modules from loading and unload them if currently resident:

sudo 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"
sudo update-initramfs -u -k all

The update-initramfs step (Canonical's recommendation) ensures the deny rule is honored across early-boot module-loading paths. If rmmod fails because the modules are in use, a reboot is required to fully unload them. Disabling only one or two of the three modules leaves the other vulnerability path exploitable; all three must be denied to close the chain.

For hosts that genuinely need IPsec ESP (StrongSwan, libreswan, other VPN deployments) or AFS, the deny is not a free action. Restrict tenancy on those hosts so the local-attacker prerequisite does not apply (no untrusted users, no CI workload, no container tenants), or carve those hosts out of the deny and document the carve-out as part of your mitigation attestation. In practice, the broad fleet (application servers, container hosts, CI runners, jump hosts) does not need ESP, so the per-host application is straightforward and the carve-outs are a small minority of hosts.

If you carry a Copy Fail mitigation, validate that both sets of controls are in place on the same host:

modinfo algif_aead | grep filename
cat /proc/cmdline | grep initcall_blacklist
lsmod | egrep '^(esp4|esp6|rxrpc)'
ls /etc/modprobe.d/dirtyfrag.conf

Federal context

As of May 8, neither Dirty Frag CVE is on the CISA Known Exploited Vulnerabilities catalog. Copy Fail (CVE-2026-31431) was added on May 1 with a May 15 federal remediation deadline under BOD 22-01. Given that Dirty Frag shares the bug class, has a public PoC and a public exploit, and has the same multi-tenant-cluster implications, KEV addition is a plausible outcome if exploitation in the wild is observed. The 14-day BOD 22-01 cadence applied to Copy Fail would, applied to Dirty Frag, set a federal remediation deadline well before any RHEL or Ubuntu vendor kernel ships. Federal customers running RHEL, OpenShift, or Ubuntu on production infrastructure should treat Dirty Frag with KEV-equivalent urgency and apply the modprobe deny now, ahead of any catalog update. The control is documented in vendor advisories from Canonical and Red Hat, so it satisfies the vendor-recommended-mitigation clause of BOD 22-01 directly.

Detection during the patch window

There is no clean network signature for an LPE that runs entirely in kernel memory. File-integrity tooling will not catch it: the corruption lives in the page cache, the on-disk binary is byte-for-byte identical to a clean install, and AIDE, Tripwire, rpm -V, and EDR file-hashing will all report green. The behavioral signals worth instrumenting during the patch window are the unexpected loading of esp4 / esp6 / rxrpc on hosts that should not use them, socket(AF_RXRPC, ...) and AF_ALG syscalls from unprivileged processes, unprivileged user-namespace creation in unusual contexts, and the echo 3 > /proc/sys/vm/drop_caches cleanup step that the public PoC uses to evict the corrupted cache page. These signals are noisier than disk-resident IOCs and require behavioral baselines. If your detection plan is the only control standing between an attacker with a shell and root, the modprobe deny is a higher-confidence layer to add underneath.

Where Tailwind stands

We've published the full operational advisory, TRG-SA-2026-004, with the per-distribution patch state, the deployment caveats for IPsec/AFS hosts, the multi-tenant Kubernetes analysis, the detection signals worth instrumenting during the patch window, and our independent assessment of why the in-place decryption bug class is unlikely to stop at three CVEs. Customers who purchased Linux platforms or services through Tailwind have received it directly. If you are not on our customer list and want a copy, request it here.

For customers asking us to assist with the rollout: the mitigation is two configuration files applied via your existing configuration-management tooling, with a per-host attestation of which modules are denied and which hosts are documented carve-outs. We can help with the attestation framing, the carve-out justification text for your security and compliance team, and the validation pass that confirms the deny is in place across your inventory. We are also tracking distribution kernel availability against our customers' fleets and will issue a Rev.A update when the additional vendor fixes ship.

The right operational stance for May is to assume additional CVEs in this family will land before the year is out. Patch the ones that exist as soon as vendor kernels ship, treat the mitigation pattern (identify candidate modules, assess legitimate consumers, apply per-host modprobe deny, document carve-outs, reboot or rebuild) as a reusable runbook for kernel-LPE class CVEs, and instrument the detection signals listed above so the next disclosure does not require new tooling. The next time a researcher posts to oss-security with another in-place decryption module, the only thing that needs to change in the runbook is the module name.