A proof-of-concept exploit for a new Linux kernel local privilege escalation vulnerability has been published under the informal name Dirty Frag, describing two interacting flaws in the kernel’s xfrm-ESP IPSec implementation and the RxRPC (Rx Remote Procedure Call) page-cache write path. The exploit chains these vulnerabilities to achieve deterministic, race-condition-free root code execution from an unprivileged local account on virtually all current Linux kernel versions across major distributions.
The research team’s disclosure characterises Dirty Frag as a spiritual successor to the CopyFail vulnerability (CVE-2026-31431, which entered CISA KEV in May 2026 following active exploitation confirmation), noting that while CopyFail relied on a copy-on-write race condition that made exploitation timing-dependent, Dirty Frag’s approach is fully deterministic — the exploit succeeds reliably on the first attempt without requiring multiple retries.
Technical Summary
Dirty Frag exploits two bugs in interaction:
Bug 1 — xfrm-ESP page pinning: The kernel’s IPSec xfrm-ESP (Encapsulating Security Payload) implementation contains a flaw in how it handles page-pinned memory during ESP packet assembly when the source buffer spans a page boundary. Under specific conditions, the pinned memory can be released while a reference to it remains active.
Bug 2 — RxRPC page-cache write primitive: A separate flaw in the RxRPC subsystem’s page-cache write path allows controlled overwrite of a 4-byte value at a calculated offset within the released page once it has been reallocated by a different kernel subsystem.
The exploit chains these two bugs: the first provides the use-after-free primitive to create the target freed page, and the second provides a controlled write primitive to that page. The write is directed at specific kernel data structures that, when corrupted with a calculated value, result in the attacker’s process obtaining a credential structure indicating root privileges (uid=0, gid=0, all capabilities).
Because the primitive does not depend on race condition timing — the page-cache write is a single atomic operation against a page the attacker controls the allocation of — the exploit succeeds deterministically.
Affected Systems
Testing confirms reliable exploitation on:
- Ubuntu 22.04 LTS, 24.04 LTS
- RHEL 9.x, CentOS Stream 9
- AlmaLinux 9.x, Rocky Linux 9.x
- Fedora 41, 42
- openSUSE Leap 15.6
The vulnerability is present in kernel versions 5.10 through 6.9 (current upstream). Kernels prior to 5.10 do not implement the RxRPC xfrm path in the form that makes this chain viable.
No Patch Available at Time of Disclosure
No CVE ID has been assigned and no kernel patch has been submitted to the Linux kernel mailing list at time of disclosure. The research team states that they disclosed the vulnerability to the Linux kernel security team under coordinated disclosure on 21 April 2026 — two weeks before public release — in accordance with the kernel security team’s 14-day disclosure timeline for vulnerabilities with public PoC.
Until a kernel patch is available through distribution security updates, mitigations are limited:
Deploy seccomp profiles: Restricting access to the AF_KCM/AF_RXRPCthat socket families via seccomp policies eliminates the RxRPC surface. Docker, Kubernetes default seccomp profiles, and AppArmor profiles for containerised workloads typically restrict this already.
Monitor for exploitation: The exploit sequence generates characteristic kernel log patterns during the page reallocation phase. Security monitoring platforms with kernel audit visibility can detect exploitation attempts before they complete.
Prioritise kernel update velocity: Once distribution patches are available, treat this as an emergency patch given the deterministic, PoC-published nature of the vulnerability. The key risk window is the period between PoC publication and patch availability — during which any adversary or red team with local access to a Linux system can trivially escalate to root.
For containerised environments: privilege escalation from an unprivileged container process to host root is possible if the kernel version is vulnerable and the exploit binary can be executed inside the container. Evaluate whether containers in your environment have the ability to execute this attack path.
Share this article