Dirty Frag: What You Need to Know and How to Respond

On May 7, security researcher Hyunwoo Kim (@v4bel) published a working proof-of-concept for a Linux kernel local privilege escalation chain he calls Dirty Frag. The disclosure happened earlier than planned because the embargo on linux-distros was broken by a third party. Distribution backports were not in place when the PoC went public.

The chain comprises two flaws, now tracked as:

• CVE-2026-43284 – xfrm-ESP Page-Cache Write. Patched in mainline at commit f4c50a4034e6. Distribution backports pending.

• CVE-2026-43500 – RxRPC Page-Cache Write. Reserved for tracking. No patch in any tree at time of writing.

Both sit underneath the broader class AWS describes as "DirtyFrag" in Bulletin 2026-027-AWS, related to the original CVE-2026-31431 (Copy Fail). Critically, the Copy Fail mitigation that many teams already deployed (an algif_aead blacklist) does not stop Dirty Frag.

To help your team respond before backports land, Automox has released an Automox Worklet™ that mitigates both variants on managed Linux endpoints. Source is freely available regardless of whether you are an Automox customer or not.

• Linux - Security - Mitigate Dirty Frag Vulnerability

If you're not yet an Automox customer, the source is published on GitHub for you to review and run manually.

The Worklet writes /etc/modprobe.d/dirtyfrag.conf with install-stubs that block all five affected modules (esp4, esp6, ipcomp4, ipcomp6, rxrpc), then attempts rmmod on each loaded module. If a module is in active use (for example, an active IPsec security association holding esp4), the unload is deferred and the endpoint is flagged for reboot. The script does not force-unload, because rmmod -f requires CONFIG_MODULE_FORCE_UNLOAD and can panic the kernel. The remediation is idempotent: running it repeatedly produces the same end state, with no additional change after the first successful run. Source is on GitHub.

Hardening

• Block the affected modules. This is what the Worklet does on managed endpoints. For everywhere else, the AWS bulletin and Hyunwoo Kim's published mitigation both recommend blocking and unloading esp4, esp6, ipcomp4, ipcomp6, and rxrpc. This breaks IPsec and RxRPC functionality, so weigh the operational impact for any host that depends on IPsec VPN tunnels or AFS clients.

• Restrict unprivileged user namespace creation. This neutralizes the ESP arm independently of module state. Set sysctl -w user.max_user_namespaces=0 on hosts that do not need user namespaces. Be aware this can break rootless containers, Snap confinement, and some browser sandboxes.

• If the modules are not loaded today, prevent future loading at the kernel level. AWS recommends sysctl -w kernel.modules_disabled=1 to lock the module set until the next reboot.

• Plan the patch path. Apply backported kernel updates from your distribution as soon as they land. Track CVE-2026-43284 and CVE-2026-43500 separately. The first will resolve through normal patch cycles. The second has no upstream fix yet, so monitor for it.

Detection

• Monitor for unexpected use of `add_key("rxrpc", ...)` and `XFRMA_REPLAY_ESN_VAL` netlink calls. Both are unusual in normal workloads. EDR and audit rules can be tuned to flag them.

• Watch for anomalous setuid execution. AWS calls this out specifically. A successful Dirty Frag exploit typically presents as an unprivileged process launching a root shell or modifying /usr/bin/su or /etc/passwd.

• Inventory loaded kernel modules across the fleet. Run lsmod | grep -E "esp4|esp6|ipcomp4|ipcomp6|rxrpc" on every Linux endpoint. Any host where these are loaded but unused is a candidate for immediate blocking.

• Check for page-cache contamination indicators. Unexpected modifications to /usr/bin/su, /etc/passwd, or other suid binaries are a strong signal. File integrity monitoring and AIDE-style baselines apply.

Transparency matters during an incident.

• The Worklet does not patch the kernel. It blocks the vulnerable modules from loading. Once your distribution publishes backports for CVE-2026-43284 and (eventually) CVE-2026-43500, you still need to apply them through your normal patch process and revert the mitigation.

• The Worklet does not apply the namespace or modules-disabled `sysctl` knobs. AWS Bulletin 2026-027 also recommends kernel.modules_disabled=1 and user.max_user_namespaces=0 as defense in depth. Both break legitimate workloads (no future module loads, breaks Docker, Chrome sandbox, Snap, Flatpak, rootless containers). The Worklet deliberately does not toggle them. Apply them manually after evaluating impact per host class.

• The Worklet does not drop the page cache. Hyunwoo Kim's published mitigation includes echo 3 > /proc/sys/vm/drop_caches to clear any contamination from prior exploitation. The Worklet skips this because it has performance implications and is only useful if you suspect prior compromise. If an endpoint was potentially exploited before remediation, drop the page cache or reboot before trusting it.

• Behavioral detection of exploitation is not included. The evaluation script confirms that the mitigation is in place. It does not look for signs that the chain was already used. Behavioral detection of anomalous add_key("rxrpc", ...), XFRMA_REPLAY_ESN_VAL traffic, and unexpected setuid execution belongs in your EDR and audit pipeline.

• IPsec, IPComp, and RxRPC dependencies are your call. The Worklet will unload the modules if it finds them. If you have hosts that depend on IPsec VPN tunnels (with or without IPComp), AFS or kafs clients, or other RxRPC consumers, exclude them from the Worklet's target groups and apply a different mitigation path.

Dirty Frag belongs to the same bug family as Dirty Pipe and Copy Fail, but it targets the frag member of the kernel's struct sk_buff rather than pipe_buffer. The exploit uses splice() to plant a reference to a read-only page-cache page (for example, /etc/passwd or /usr/bin/su) into the frag slot of a sender-side skb. Receiver-side kernel code then performs in-place cryptographic operations on that frag, modifying the page cache in RAM. Every subsequent read of the file sees the corrupted version, even though the attacker only ever had read access.

The chain has two arms:

• xfrm-ESP Page-Cache Write (CVE-2026-43284). Lives in esp_input() on the IPsec ESP receive path. When an skb is non-linear but lacks a frag list, the code skips skb_cow_data() and decrypts AEAD in place on the planted frag. Using the XFRMA_REPLAY_ESN_VAL netlink attribute, the attacker controls both the file offset and the 4-byte value of each store. This variant requires the ability to create a user namespace.

• RxRPC Page-Cache Write (CVE-2026-43500). Lives in rxkad_verify_packet_1(). It performs a single-block in-place decrypt on the first eight bytes of an RxRPC payload. Because the splice-pinned page becomes both source and destination, and because the decryption key is freely specifiable through add_key("rxrpc", ...), the attacker brute-forces the key in user space until the desired plaintext lands in the page cache. No namespace privilege required.

Either arm alone has gaps. Some Ubuntu configurations block unprivileged user namespace creation through AppArmor, which neutralizes the ESP arm. Most distributions do not ship rxrpc.ko by default, which neutralizes the RxRPC arm. Ubuntu does ship and auto-load rxrpc.ko, so the chain covers it. Chained together, the two arms cover the blind spots in each other and reach root on every major distribution Kim tested.

Tested affected platforms include Ubuntu 24.04.4 (6.17.0-23-generic), RHEL 10.1, AlmaLinux 10, CentOS Stream 10, openSUSE Tumbleweed, and Fedora 44.

The effective vulnerability window is roughly nine years. The ESP flaw has been present since kernel commit cac2661c53f3 in January 2017. The RxRPC flaw has been present since 2dc334f1a63a in June 2023.

Dirty Frag is the third generation of a bug class. Dirty Pipe targeted pipe_buffer. Copy Fail targeted the AEAD path through algif_aead. Dirty Frag targets sk_buff frag pages and chains across two unrelated subsystems to defeat both Ubuntu's namespace policy and the absence of rxrpc.ko on most distributions. Each generation has been more universal and harder to mitigate by removing one component.

The pattern that makes this class dangerous is straightforward: Linux's zero-copy networking and crypto paths frequently treat splice-pinned page-cache pages as scratch space, and any in-place operation on those pages is a write primitive against the cache. The same template applies anywhere the kernel reuses a pinned page as both source and destination.

• Public PoC availability raises the floor. Once a deterministic, reliable LPE has working code in the open, ransomware operators and red teams adopt it within days. Dirty Frag has no race window, no kernel panic on failure, and a high success rate.

• The Copy Fail mitigation is not a Dirty Frag mitigation. Teams that blocked algif_aead after CVE-2026-31431 will assume they are covered. They are not.

• More variants are likely. AWS frames this as a class rather than a specific CVE. Expect additional sk_buff page-cache write paths to surface in the same family.

Inventory your Linux fleet. Block the affected modules where you can. Restrict user namespace creation where it does not break workloads. Apply distribution backports the moment they land. Keep CVE-2026-43500 on your tracking list until an upstream patch exists.

The discipline that makes this manageable is not different in kind from any other unpatched Linux LPE. It is automation, inventory, and a clear path from "we know about it" to "every endpoint is covered." Expect more of these page-cache-write bugs, surfacing faster, as the pattern generalizes across the kernel.

Patch your kernels. Tighten your namespace policy. Verify the result.

• Hyunwoo Kim, Dirty Frag PoC and write-up

• AWS Security Bulletin 2026-027-AWS, "Dirty Frag" and other issues in Amazon Linux kernels

• oss-security: Dirty Frag: Universal Linux LPE

• oss-security: Copy Fail 2 / Dirty Frag, n-day from public commit, not embargo break

• CVE-2026-31431 (Copy Fail, parent issue)

• Automox Worklet source on GitHub