Dirty Frag in Linux: technical guide to page cache, skb fragments and local root

Dirty Frag is a Linux local privilege escalation disclosed on May 7, 2026. The technically interesting part is the class of bug: page-cache backed memory can flow into non-linear networking fragments and cryptographic paths that may write in place. If the path should have copied first but does not, a page that represents protected file data can be modified through a different kernel subsystem.

Threat model

The attacker needs local code execution. That may come from a shell, a CI job, a container, a hosted notebook, a plugin system or any service that runs user-controlled code. The risk is highest when the same kernel is shared by workloads of different trust levels.

Page cache and ownership

The page cache is not just a speed feature. It is part of the effective file access model. The kernel must preserve the invariant that a process without write permission cannot modify protected file content by reaching the cached page through another route. Dirty Frag, like Dirty Pipe in a broader sense, shows how fragile that invariant becomes when zero-copy paths cross subsystem boundaries.

skb fragments and crypto paths

Linux packets can be non-linear. sk_buff may contain references to pages rather than one contiguous buffer. That is efficient for splice, sendfile and network transmission, but later layers must know whether a fragment is private and writable. The Dirty Frag material identifies ESP4/ESP6 and RxRPC related paths as relevant. The defensive question is whether a path can receive page-cache backed fragments and then perform in-place transformation.

Mitigation

Patch the kernel through the distribution or cloud provider, then reboot or replace nodes. Prioritize CI/CD runners, Kubernetes nodes, shared development hosts and any server that executes third-party code. Until patched, use ephemeral runners, minimize secrets per job, reduce privileged containers and avoid mixing trust levels on one host.

Operational checks

Record kernel package version, loaded kernel after reboot, provider advisory, node rotation status and exceptions. Do not rely on a single PoC result. Do not assume container image updates fix the host kernel. For incident response, focus on whether untrusted local code ran on vulnerable hosts before patching and whether secrets were available there.

FAQ

Is the root cause splice?

splice and zero-copy movement are part of the relevant data-flow story, but the core security issue is writing to memory that should have been treated as shared or copied first.

Should IPsec be disabled?

Not as a blanket rule. Apply vendor fixes and evaluate exposure in your environment.

What should be patched first?

Multi-tenant hosts, CI/CD, container nodes and systems with local users or untrusted workloads.

Sources

• Openwall oss-security disclosure.
• Dirty Frag write-up.
• Dirty Frag site.
• Hacker News discussion.
• Linux kernel memory concepts.