Dirty Frag: a Linux kernel LPE chain that breaks common “safe defaults” assumptions

A newly disclosed Linux kernel local privilege escalation (LPE) issue, tracked as CVE-2026-31431 (reported CVSS 7.8 in the source), is described as unpatched and actively exploited in the wild. The public discussion frames it less as one narrow bug and more as a vulnerability class nicknamed “Dirty Frag” that can yield root from an unprivileged local user on many mainstream distributions.

What’s known (and what the term “Dirty Frag” refers to)#

Security researcher Hyunwoo Kim (@v4bel) describes Dirty Frag as a chain of two related page-cache write primitives:

• xfrm-ESP Page-Cache Write (rooted in the IPSec/xfrm subsystem)
• RxRPC Page-Cache Write (in rxrpc fast paths)

The key claim in the source is operational: chaining these two variants “covers” each other’s limitations across different distro configurations. In plain terms: one exploit path tends to work where the other is blocked by policy or missing by default.

The source characterizes this as a deterministic logic bug rather than a timing-sensitive race:

• No race condition required (per the write-up summary)
• High success rate claimed
• Kernel does not panic when the exploit fails (as described)

If that characterization holds in practice, it changes incident response posture: defenders can’t lean on “it’s a racy local exploit, it probably won’t land reliably.”

Impact and affected environments (as described)#

Successful exploitation could allow an unprivileged local user to gain root on “most Linux distributions.” The source lists examples including:

• Ubuntu 24.04.4
• RHEL 10.1
• openSUSE Tumbleweed
• CentOS Stream 10
• AlmaLinux 10
• Fedora 44

Treat that list as “reported impacted” rather than an authoritative compatibility matrix. Kernel exposure is usually more about specific kernel code paths and config/module state than the distro name, and the source material does not include a complete kernel-version boundary.

The urgency driver is that the source claims:

• The issue is unpatched at the time of writing
• There is active exploitation in the wild
• A working proof-of-concept exists that can “gain root in a single command”

That combination typically means you should assume real-world attempts will follow quickly, especially on multi-user systems or environments where untrusted code can run locally (shared servers, CI runners, university boxes, some desktop threat models, and post-compromise privilege escalation).

Why the chain matters: “blocked user namespaces” is not a silver bullet#

The two exploit paths are presented as complementary.

1) xfrm-ESP Page-Cache Write: powerful, but policy-sensitive#

The xfrm/ESP primitive is described as providing a 4-byte store primitive that can overwrite a small amount of data in the kernel’s page cache.

But there’s an important constraint in the source: triggering this path requires the attacker to create a namespace. The article notes that Ubuntu blocks unprivileged user namespace creation via sysctl controls, so in that environment the xfrm-ESP path “cannot be triggered.”

(That’s the “safe defaults” trap: you can correctly harden one common entry point and still be exposed via a different subsystem.)

2) RxRPC Page-Cache Write: avoids namespaces, but depends on module presence#

The RxRPC variant is described as not requiring the privilege to create a namespace. However, the source also notes a different practical limitation: the rxrpc.ko module is not included in most distributions.

The example given is that a default RHEL 10.1 build does not ship rxrpc.ko, while on Ubuntu the module is loaded by default.

The net effect: the “blind spots cover each other”#

Kim’s point (as quoted) is that chaining the variants means you often get one workable path:

• Where unprivileged user namespaces are allowed, the xfrm/ESP path can run first.
• Where user namespaces are blocked but RxRPC is present (Ubuntu is the named example), the RxRPC path can work.

From a defender’s perspective, this is the real headline: the exploit strategy is tuned to configuration reality, not to a single ideal target. It makes “we disabled X” less reassuring unless you have validated the full set of reachable code paths on your specific fleet.

Technical shape: what the bug is described to be doing#

The source includes a more specific description attributed to AlmaLinux: the flaw resides in an “ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path” and is reachable via the XFRM user netlink interface.

The broader described pattern is:

• The receive path decrypts in place over page fragments.
• Those fragments may be externally-backed pages (e.g., pipe pages attached via splice(2), sendfile(2), MSG_SPLICE_PAGES).
• If the kernel decrypts directly over pages that a user process still references, plaintext can be exposed or corrupted, and a write-primitive into page cache becomes possible.

You do not need to internalize every kernel subsystem named here to act. The takeaway is that the affected surface spans:

• IPSec/xfrm ESP fast paths (esp4, esp6)
• RxRPC fast paths (rxrpc)
• Splice/sendfile style mechanisms that move page-backed buffers without copies

What not to overclaim#

The source material is thin on hard boundaries, so be careful with statements that sound definitive.

Do not assume, based on the article alone:

• Which exact kernel versions are vulnerable (the source references commits from 2017 and 2023 but does not provide a clean affected-range table).
• Whether exploitation “in the wild” is broad or targeted. It is reported as active, but no victimology is provided.
• That a specific mitigation eliminates risk everywhere. The chain is explicitly designed to avoid single-point mitigations.

Also note the warning in the source: Dirty Frag overlaps with prior “Copy Fail” discussions but is described as not dependent on whether algif_aead is enabled. So applying a known mitigation that blocklists algif_aead (for Copy Fail) should not be treated as coverage for Dirty Frag.

Practical takeaways: what you can do before patches land#

If you operate Linux systems where untrusted users can execute local code (or where post-compromise LPE materially worsens impact), you want to reduce reachable attack surface quickly.

The source suggests a direct mitigation: blocklist the esp4, esp6, and rxrpc modules so they cannot be loaded, and unload them if currently loaded.

It provides an example command:

sudo sh -c "printf 'install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Before applying that broadly, sanity-check impact:

• Blocking esp4/esp6 can affect IPSec/ESP usage. If you rely on kernel IPsec, this is not a free change.
• Blocking rxrpc can affect environments that use RxRPC/AFS-related functionality.
• On some fleets, modules may be built-in rather than loadable; blocklisting won’t help there.

Operationally useful next checks:

• Confirm whether esp4, esp6, rxrpc are loadable modules on your kernel and whether they are currently loaded.
• Review whether unprivileged user namespaces are enabled on your systems, and don’t treat “disabled” as sufficient on its own.
• Track vendor advisories for your distro and kernel line; you need the eventual fixed kernels and backports, not only module workarounds.

If your environment supports it, add telemetry:

• Watch for unusual module load attempts (modprobe events) involving esp4, esp6, rxrpc.
• Monitor suspicious use of splice, sendfile, or MSG_SPLICE_PAGES patterns from untrusted processes (this is noisy, but can be helpful in targeted environments).

Bottom line#

Dirty Frag is being framed as a reliable, configuration-aware local root chain against Linux kernels, with a public PoC and reported active exploitation. The defensive lesson is not “block one feature and move on,” but “validate which kernel subsystems are reachable on your specific fleet, and reduce exposure until patches arrive.”