Dirty Frag - Unpatched Universal Linux Kernel Local Privilege Escalation

Executive Summary

On 7 May 2026, Korean security researcher Hyunwoo Kim (@v4bel) was forced to publicly disclose a previously embargoed universal Linux kernel local privilege escalation he has named "Dirty Frag." A third party broke the coordinated disclosure embargo earlier the same day by independently publishing one of the two underlying exploits, leading Kim - in consultation with the linux-distros security list - to release the full chain along with a working proof-of-concept on GitHub. No CVE has yet been assigned, no distribution has shipped a patched kernel, and a fully weaponised exploit is already in public circulation.

Dirty Frag chains two independent Linux kernel page-cache write primitives - one in the xfrm/IPsec ESP path (vulnerable since January 2017) and one in the RxRPC/rxkad subsystem (vulnerable since June 2023) - to obtain reliable root execution from any unprivileged local account. Crucially, the RxRPC variant does not require the attacker to create a user namespace, removing the only meaningful prerequisite that limited the closely related "Copy Fail" vulnerability (CVE-2026-31431) disclosed last week. Dirty Frag is effective on hosts where the Copy Fail mitigation (algif_aead blacklist) has already been applied. The exploit is deterministic, does not rely on a race condition, does not panic the kernel on failure, and produces near-100% success across every confirmed target.

Confirmed-affected distributions include Ubuntu 24.04.4, Red Hat Enterprise Linux 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, and openSUSE Tumbleweed - covering kernels up to 7.0.x. Because the vulnerable code lives in long-standing networking and IPC modules (esp4, esp6, rxrpc) that are present and loadable on virtually every mainstream Linux build, Monachus customers should assume their entire Linux estate is exposed until vendor patches arrive. The only mitigation currently available is to blacklist and unload the vulnerable modules immediately. This advisory should be treated as a priority emergency response event by every Monachus customer operating Linux servers, container hosts, or Kubernetes nodes.

Vulnerability Details

Dirty Frag is a logic-level extension of the bug class previously demonstrated by Dirty Pipe (CVE-2022-0847) and Copy Fail (CVE-2026-31431). In each of these vulnerabilities, an attacker abuses a kernel zero-copy send path in which splice() plants a reference to a page-cache page into the fragment slot of a sender-side socket buffer (skb), and a receiver-side kernel routine subsequently performs an in-place crypto operation directly on top of that page-cache fragment. The result is a controlled write into the page cache of any file the attacker can read - which, after the kernel later loads that file as code, executes the attacker's bytes with the privileges of whoever invokes it next.

The novelty of Dirty Frag is that it identifies two distinct kernel paths exhibiting this pattern, and chains them to deliver a single universal exploit:

Because the RxRPC primitive does not require namespace creation, it bypasses the most common compensating control deployed against the previous-generation Copy Fail vulnerability - namely, restricting unprivileged_userns_clone. The xfrm-ESP primitive is then used opportunistically where it offers a stronger write shape. Either path alone is sufficient on most systems; the chain is what makes Dirty Frag genuinely universal.

As with Copy Fail, the page cache is host-wide and is not namespaced. An attacker corrupting the cached image of a setuid binary such as /usr/bin/su, /usr/bin/sudo, or /usr/bin/passwd obtains an immediate root shell when the binary is next executed. The on-disk file is unchanged, which complicates host-based integrity monitoring. The same primitive is viable as a container escape from any unprivileged container in which the vulnerable modules are reachable from the workload.

Working exploit code is already public. There is no vendor patch. Any unprivileged local account on a Linux system running an affected kernel - including untrusted container workloads, CI/CD runners, shared developer hosts, and multi-tenant cloud environments - should be assumed capable of obtaining root within seconds. The mitigation in this advisory must be applied today.

Exploitation Prerequisites

Dirty Frag does not require: network ingress to the target, administrator or sudo rights, any specific application to be running, or attacker physical access. The Copy Fail-era mitigation of blacklisting algif_aead does not protect against Dirty Frag.

Attack Chain

1. Step 1 - Local Foothold: The attacker obtains any unprivileged local execution context on the target - a shell account, a compromised application, an untrusted container, a CI/CD job, or post-exploitation foothold from a web vulnerability.
2. Step 2 - Choose Primitive: The exploit selects the RxRPC path by default (no namespace privilege needed). On systems where user-namespace creation is permitted, the xfrm-ESP path is used opportunistically for its stronger 4-byte write shape.
3. Step 3 - Pin Page-Cache Page via Splice: The exploit opens the appropriate socket and uses splice() to plant a reference to a page-cache page (backing a chosen target file, e.g. /usr/bin/su) into the fragment slot of a sender-side skb.
4. Step 4 - Trigger In-Place Crypto Write: The exploit drives the receiver-side path: in the RxRPC case, an 8-byte pcbc(fcrypt) in-place decrypt with an attacker-brute-forced key is performed directly on the pinned page-cache page; in the xfrm-ESP case, a controlled 4-byte STORE is executed against the same kind of pinned page.
5. Step 5 - Corrupt Setuid Binary in Cache: The crypto operation overwrites attacker-controlled bytes of the cached image of a setuid binary, neutering the privilege-drop check or otherwise redirecting execution.
6. Step 6 - Execute and Obtain Root: The attacker invokes the corrupted binary. The kernel runs the modified in-memory image, which executes as root and drops the attacker into a root shell. The on-disk file is untouched.
7. Step 7 (Optional) - Container Escape: Performed from inside an unprivileged container, the same chain corrupts host-visible binaries via the shared, non-namespaced page cache, escalating from container-root to host-root and breaking namespace isolation.

Vendor Response

At the time of writing, no upstream Linux kernel patch and no distribution-vendor fix is publicly available for Dirty Frag. No CVE identifier has been assigned. The chain was disclosed publicly only after a third party broke the coordinated embargo by independently releasing the xfrm-ESP exploit on 7 May 2026; the researcher and the linux-distros coordination list elected to publish the full write-up rather than leave defenders to face a partial public exploit blind.

Vendor positions known at time of publication:

Monachus expects coordinated stable-kernel updates from the major distributions in the days following this advisory. This advisory will be revised once vendor patches and CVE assignment are published.

Immediate Mitigation Recommendations

Tier 1 - Immediate (Within 24 Hours)

1. Blacklist and unload the vulnerable kernel modules on every Linux host: This is the only currently effective mitigation. On every affected system, run:

   cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
   install esp4 /bin/false
   install esp6 /bin/false
   install rxrpc /bin/false
   EOF
   rmmod esp4 esp6 rxrpc 2>/dev/null || true

   The install ... /bin/false directives prevent the modules from being autoloaded by unprivileged operations. The rmmod command unloads any currently loaded instances. The configuration persists across reboot. Do not skip this step on any host pending a kernel update.
2. Confirm the Copy Fail mitigation is also still applied: Dirty Frag is independent of Copy Fail (CVE-2026-31431) - applying the Dirty Frag module blacklist does not remove the need for the Copy Fail mitigations described in MNSA-2026-005. Both must be in place until kernel patches are available for both issues.
3. Validate compatibility before mass rollout: Disabling esp4/esp6 will break IPsec/ESP tunnels (e.g. some site-to-site VPNs, strongSwan/Libreswan deployments). Disabling rxrpc will break AFS clients (rare in most enterprises). Identify any systems that legitimately depend on these modules - typically a small minority - and triage them separately under heightened monitoring while you await vendor patches.
4. Restrict unprivileged user-namespace creation where it is not required: This blunts the xfrm-ESP variant on hosts where the module cannot be removed. On Debian/Ubuntu, set the Debian-specific sysctl kernel.unprivileged_userns_clone=0, which blocks user-namespace creation only for unprivileged users. On RHEL-family and any upstream kernel from 4.9 onward, set the upstream sysctl user.max_user_namespaces=0; note that this disables user-namespace creation in the current namespace entirely (including by root) and may break legitimate workloads such as rootless Podman, Bubblewrap, or unprivileged container builders. Validate compatibility before applying broadly. Neither setting mitigates the RxRPC variant.
5. Hunt for active exploitation: Review system logs for unexpected privilege escalation events, unexplained root-owned processes spawned from non-root parents, anomalous su/sudo invocations, and any module-load events for esp4, esp6, or rxrpc on systems where they are not in legitimate use. Enable auditd rules for setuid execution if not already in place.

Tier 2 - Short-Term (Within 1–2 Weeks)

1. Inventory and confirm coverage: Identify every Linux system in your estate - including cloud instances, on-premises servers, developer workstations, CI/CD runners, Kubernetes nodes, container hosts, and managed appliances. Confirm via configuration-management tooling (Ansible, Chef, Puppet, Salt) that the /etc/modprobe.d/dirtyfrag.conf file is present and the modules are not loaded (lsmod | grep -E 'esp4|esp6|rxrpc' returns empty).
2. Apply vendor kernel updates the moment they are released: Subscribe to security advisories from your distributions (USN, RHSA, SUSE-SU, DSA, ALAS, CloudLinux). Define an emergency-patching pathway with a target deployment window of 72 hours from vendor release for this issue.
3. Tighten container runtime defaults: Apply seccomp profiles that deny socket() calls for AF_RXRPC and any unused address families. Confirm Kubernetes PodSecurityAdmission "restricted" baselines are enforced. Audit container images for unnecessary capabilities such as CAP_NET_ADMIN and CAP_SYS_ADMIN.
4. Treat shared and multi-tenant systems as highest priority: Shared CI/CD workers, jump hosts, bastion hosts, developer VMs, university or research clusters, and any hosts with multiple local user accounts must be patched first. Where patching is not yet possible, suspend non-essential local access until mitigations are confirmed.

Tier 3 - Medium-Term (Within 30 Days)

1. Add Dirty Frag detection signatures to vulnerability scanners: Many scanners will rely on kernel version checks once a CVE is assigned. In the interim, configuration checks for the presence of the dirtyfrag.conf blacklist file or the absence of loaded esp4/esp6/rxrpc modules can serve as a compensating control indicator.
2. Review your kernel hardening baseline: Re-evaluate seccomp defaults, capability restrictions, Yama LSM, restricted user-namespace settings, and module-loading policies. Consider enforcing module signing via the module.sig_enforce=1 kernel boot-line parameter (or the equivalent CONFIG_MODULE_SIG_FORCE=y build-time option) backed by a tightly controlled signing policy, and maintain a default-deny module allowlist for production fleets.
3. Validate runtime detection coverage: Confirm that EDR / runtime-security tooling (Falco, Sysdig Secure, Aqua, Tetragon, etc.) generates alerts for unexpected loading of esp4, esp6, or rxrpc modules and for anomalous setuid binary invocation patterns.
4. Conduct a tabletop exercise on unpatched-kernel response: Dirty Frag is the second universal LPE in the same bug class disclosed inside 10 days. Use this incident to walk your incident-response and platform teams through the decision-making and communications required when vendor patches are not yet available.

Tier 4 - Strategic

1. Adopt live kernel patching across production: The Dirty Frag/Copy Fail cluster makes the case for live patching unambiguous. Evaluate or expand deployments of KernelCare, Canonical Livepatch, SUSE Live Patching, or Red Hat kpatch so that future kernel CVEs of this severity can be remediated without a fleet-wide reboot.
2. Define and enforce an emergency-patch SLA for kernel CVEs: For Critical/High kernel LPEs with public exploits and no patch, your SLA should require mitigation within 24 hours and patching within 72 hours of vendor release. Document this in your security policy and validate against it after every event of this class.
3. Reduce the kernel attack surface as a baseline: Many of the modules implicated in this and previous page-cache-write vulnerabilities (algif_aead, esp4, esp6, rxrpc, etc.) are not used by typical workloads. A standing module allowlist that disables IPsec ESP, RxRPC, AF_ALG, and other rarely-used network/crypto modules on hosts that do not need them would have pre-empted exploitation of these issues by default.
4. Strengthen container isolation beyond namespaces: Page-cache-write vulnerabilities repeatedly demonstrate that namespace-based isolation alone is insufficient against a determined local attacker. Treat untrusted workloads as requiring strong kernel isolation - gVisor, Kata Containers, or hardware-based isolation (Firecracker microVMs, AWS Nitro, GCP Confidential VMs) - rather than relying solely on cgroups and namespaces.

Ecosystem Context

Dirty Frag is the fourth high-impact Linux kernel page-cache-corruption vulnerability disclosed in the past decade, and the second in the same bug class to surface in the past two weeks:

The pattern is clear: zero-copy send paths combined with in-place receiver-side crypto operations on page-cache-backed fragments form a recurring foot-gun in the Linux kernel. Dirty Frag is the first member of this class to be disclosed without a patch in hand, which raises the operational stakes considerably for defenders.

Compliance Implications

SOC 2

• CC7.1 - Vulnerability Detection: Detection of an actively exploitable vulnerability with no vendor patch is a stress-test of your detection-and-response programme. Auditors will expect to see evidence that Dirty Frag was identified in your inventory rapidly, communicated internally, and tracked to closure.
• CC7.2 - Vulnerability Remediation: Where no vendor patch is available, compensating controls (module blacklists, namespace restrictions, runtime monitoring) must be deployed and documented. The decision-making and authorisation around emergency mitigations should be auditable.
• CC6.1 - Logical Access Controls: A vulnerability that elevates any local user to root undermines the least-privilege principle. Documented compensating controls for shared and multi-tenant systems must be in place until patches are deployed.
• CC6.6 - Logical Access Restrictions: Systems with multiple local users - CI/CD runners, developer environments, jump hosts - must receive priority mitigation, with access restricted where feasible until patched.
• CC9.1 - Risk Mitigation: Embargo-broken disclosures are a recognised risk. Your incident-response programme should explicitly contemplate this scenario.

ISO 27001:2022

• A.8.8 - Management of Technical Vulnerabilities: Requires timely identification and remediation of technical vulnerabilities. With no CVE yet assigned, organisations must rely on internal advisory tracking; documented evidence of triage and mitigation is essential.
• A.8.15 - Logging: auditd coverage for setuid execution and kernel module loading should be confirmed and retained for the duration of the unpatched window.
• A.8.22 - Segregation of Networks: Container-escape capability via shared page cache reinforces that namespace isolation is not a network-segmentation control. Network-level segmentation between container workloads and host-management planes is required.
• A.5.29 - Information Security During Disruption: Emergency-patching procedures must be invoked. Document the decision to apply the module-blacklist workaround in advance of vendor patching.
• A.5.7 - Threat Intelligence: The embargo break is a textbook case requiring threat-intelligence-driven response. Demonstrate that intelligence sources were monitored and acted upon promptly.

Conclusion

Dirty Frag is the rare combination defenders dread: a universal, deterministic, root-yielding Linux kernel exploit, with working public proof-of-concept code, against every major distribution, and with no vendor patch yet available. Its disclosure was forced by an embargo break, which compresses the usual response timeline to zero. The mitigation, however, is straightforward - a single configuration file blacklisting three rarely-used kernel modules, deployable in under a minute per host with negligible operational impact for the vast majority of environments.

Every Monachus customer should deploy the esp4/esp6/rxrpc module blacklist across their full Linux estate today, alongside the existing Copy Fail mitigation, and prepare an emergency kernel-patching cycle for the moment vendor updates are released. Treat any Linux system to which untrusted local execution has been granted - including container workloads, CI/CD runners, and shared hosts - as already compromised until both mitigations are confirmed in place.

References

• oss-security - Dirty Frag: Universal Linux LPE (Hyunwoo Kim)
• seclists.org - oss-sec mirror of the Dirty Frag disclosure
• GitHub - V4bel/dirtyfrag (proof-of-concept and exploit chain)
• GitHub - V4bel/dirtyfrag README (mitigation guidance)
• GitHub - V4bel/dirtyfrag technical write-up
• LWN.net - Dirty Frag: a zero-day universal Linux LPE
• CloudLinux - Dirty Frag [CVE Pending]: Mitigation and Kernel Update
• Cyber Kendra - Dirty Frag: No Patch, No Warning, Root on Every Major Linux Distro
• Hacker News - Dirtyfrag: Universal Linux LPE
• DirectAdmin Forums - Mitigation for Dirty Frag
• Monachus - MNSA-2026-005: Copy Fail (related advisory)