Privilege Escalation on KnightLi Blog

Dirty Frag, Copy Fail, and Fragnesia: Comparing Three Recent Linux Local Privilege Escalation Flaws

Fri, 15 May 2026 13:24:04 +0800

Several high-profile Linux kernel local privilege escalation vulnerabilities have appeared recently: Dirty Frag, Copy Fail, and Fragnesia. They look like a single family of events because the end result is similar: a low-privilege local user may be able to become root.

But from an operations perspective, they should not be treated as one vulnerability. Their entry modules, trigger paths, mitigation options, and patch timelines differ. A better way to understand them is this: they expose a shared risk around the complex boundary between the Linux page cache, splice, socket buffers, and crypto paths.

This post only covers risk and response analysis. It does not include reproducible exploitation steps.

What the Three Flaws Are

Dirty Frag: CVE-2026-43284

Dirty Frag mainly points to a page-cache write issue in the Linux kernel networking path. Public write-ups usually discuss it together with two issues: the xfrm-ESP side, CVE-2026-43284, and the rxrpc side, CVE-2026-43500.

CVE-2026-43284 is related to in-place decryption when ESP handles shared skb fragments. The key point is not that an attacker directly modifies a disk file, but that the kernel can write to shared pages it should not modify, affecting file contents in the page cache.

Operationally, remember that Dirty Frag reaches esp4, esp6, and rxrpc, a set of kernel modules and networking subsystem paths. It is tied to IPsec, ESP, and RxRPC, so temporary mitigation also focuses on those modules.

Copy Fail: CVE-2026-31431

Copy Fail is a Linux kernel local privilege escalation vulnerability disclosed by Theori / Xint Code. Its entry point is not the IPsec networking path, but the kernel userspace crypto API around algif_aead / AF_ALG.

Public explanations describe it as originating from an in-place optimization introduced in 2017. In some cases, the kernel failed to copy data as expected and instead placed page-cache pages into a writable destination path. An attacker can combine AF_ALG with splice() to perform a small controlled write to page-cache-backed pages.

Its risk comes from strong exploitability and broad impact across mainstream distributions. Unlike Dirty Frag, Copy Fail’s temporary mitigation focuses on restricting or disabling algif_aead, and on limiting AF_ALG socket creation in container and CI environments.

Fragnesia: CVE-2026-46300

Fragnesia is another Linux kernel local privilege escalation vulnerability disclosed by V12 Security, and it belongs to a similar attack surface as Dirty Frag. It is not the same bug as Dirty Frag, but it still revolves around IPsec ESP / rxrpc related modules and page-cache write effects.

AlmaLinux describes it as the third local-root issue in the same broad code area. The key problem is that skb_try_coalesce() did not preserve the shared-fragment marker when coalescing socket buffer fragments, which could later let the XFRM ESP-in-TCP receive path decrypt in place over external page-cache pages.

In short, Fragnesia is closer to Dirty Frag. Both revolve around esp4, esp6, rxrpc, skb fragments, and ESP decryption paths. Their temporary mitigations also overlap heavily.

Similarities: Why They Are Dangerous

The common thread is not that the exact code locations are identical, but that the attack outcome and risk model are very similar.

First, all three are local privilege escalation issues. Attackers usually need ordinary local code execution first, then they can attempt to become root. For a single-user desktop this is not remote one-click compromise; for multi-user servers, CI runners, container hosts, shared development machines, and VPS instances with exposed SSH, low-privilege entry points are not rare.

Second, all three involve page-cache writes. Attackers may not permanently modify the file on disk; instead, they affect the in-memory page-cache copy. This makes traditional integrity checks less reliable: the disk hash can remain normal while the execution path reads polluted page-cache content.

Third, they are closer to deterministic logic bugs than timing-sensitive race conditions. Public material repeatedly notes that these issues do not require winning a race condition. Defenders should not underestimate exploit reliability based on older assumptions.

Fourth, they amplify the risk of container and automation environments. Low-privilege code inside containers, CI jobs, build scripts, or third-party plugins can turn a “local issue” into a platform-level issue if it can reach the relevant host kernel interfaces.

Differences: One Mitigation Does Not Cover All

The biggest difference is the entry module.

Copy Fail’s critical entry point is algif_aead / AF_ALG, part of the kernel userspace crypto API. Its temporary defense focuses on disabling or restricting algif_aead, and using seccomp to block containers from creating AF_ALG sockets.

Dirty Frag’s critical entry point is xfrm-ESP and rxrpc. It is closer to protocol and socket buffer handling paths. Temporary defense typically considers disabling esp4, esp6, and rxrpc, but that can affect IPsec, VPNs, tunnels, or related networking capabilities.

Fragnesia sits in a similar region to Dirty Frag, but the concrete issue is that skb_try_coalesce() did not preserve the shared-fragment marker. It is more like another branch of the Dirty Frag risk surface than a Copy Fail crypto API issue.

So, fixing Copy Fail does not mean Dirty Frag and Fragnesia are covered. Likewise, disabling esp4 / esp6 does not automatically remove Copy Fail. Their patch state and mitigation strategy must be checked separately.

How to Judge Exposure

For these vulnerabilities, do not judge only by distribution name or kernel major version. Distributions backport fixes, cloud vendors maintain their own kernel branches, and enterprise distributions may carry additional patches.

A safer sequence is:

Check the distribution security advisory and kernel package changelog.
Verify whether the current kernel package fixes the relevant CVE.
For cloud servers, container hosts, and CI nodes, also check cloud or platform advisories.
For temporary mitigations, confirm whether the business depends on the affected module.
After a kernel update, schedule a reboot and confirm the running kernel has changed.

The most common trap is “the package is updated, but the machine has not rebooted.” Kernel vulnerabilities are not like ordinary userspace service updates. Until the system boots into the new kernel, the old kernel may still be running.

Operational Priority

The systems that deserve the highest priority are not all Linux machines equally. Start where low-privilege code execution is most likely.

Highest-priority environments include:

Multi-user login servers
CI / CD runners
Build and artifact packaging machines
Container hosts and Kubernetes nodes
Shared development machines
Cloud servers and VPS instances exposing SSH
Platforms running third-party scripts, plugins, or job queues
Machines with web vulnerabilities, weak passwords, or historical compromise signals

Closed, single-user machines with no external code execution entry point are still at risk if vulnerable, but they can usually be handled later.

How to Treat Temporary Mitigation

Temporary mitigation is not a replacement for a patch. Its value is reducing exposure when you cannot immediately reboot or are waiting for distribution packages.

For Copy Fail, focus on algif_aead and AF_ALG. If the business does not use the kernel AF_ALG crypto interface, evaluate disabling the related module. In container environments, check seccomp policies first so untrusted workloads cannot freely create the relevant socket.

For Dirty Frag and Fragnesia, focus on esp4, esp6, and rxrpc. If the system does not depend on IPsec ESP, related VPNs, tunnels, or RxRPC, consider temporary disabling. Do not do this blindly in production because these modules may support real networking workloads.

The final path is still a kernel update. Temporary mitigation can reduce attack surface, but it cannot prove the system is fully safe.

What These Three Flaws Tell Us

The important warning is not just the number of CVEs. These flaws all cluster around high-complexity kernel paths: zero-copy, splice, socket buffers, the page cache, crypto interfaces, and protocol-stack optimizations.

These paths deliver performance, but their ownership boundaries are hard to maintain. Whether a fragment is shared, whether a page may be written in place, and whether an optimization truly only reduces copying all become security boundaries.

For security and operations teams, the takeaways are practical:

Treat local privilege escalation as an amplifier for existing low-privilege entry points.
Containers are not a natural isolation boundary for kernel vulnerabilities.
File integrity checks cannot look only at disk contents.
CI, build machines, and plugin platforms are high-priority assets.
Kernel patching requires verifying both “installed” and “running” states.

Summary

Dirty Frag, Copy Fail, and Fragnesia are all high-priority recent Linux local privilege escalation events, but they are not three names for one vulnerability.

Copy Fail goes through the algif_aead / AF_ALG crypto API path. Dirty Frag goes through xfrm-ESP and rxrpc. Fragnesia, in a nearby Dirty Frag attack surface, again triggers page-cache write risk through skb fragment marker handling.

Operationally, the safest response is to update the kernel according to distribution advisories and reboot. For systems that cannot be updated immediately, evaluate temporary module disabling or tighter seccomp rules based on the actual vulnerability entry point. Prioritize multi-tenant systems, CI, container hosts, and shared development environments.

References:

Theori Copy Fail notes: https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail advisory: https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag notes: https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia notes: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC notes: https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300): Impact and Mitigation for a Linux Kernel Local Privilege Escalation Flaw

Fri, 15 May 2026 13:18:01 +0800

The Linux kernel has another local privilege escalation issue in the same broad attack surface as Dirty Frag: Fragnesia (CVE-2026-46300).

According to V12 Security, Fragnesia is a Linux local privilege escalation vulnerability. An attacker does not need existing high privileges on the host. If they can execute local code, they may be able to abuse a logic flaw in the kernel’s XFRM ESP-in-TCP subsystem to modify read-only file contents through the page cache and eventually trigger a root shell.

Source:

V12 Security PoC notes: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

This post does not cover reproducible exploitation steps. It focuses on the operational risk and response path.

How It Relates to Dirty Frag

V12 Security classifies Fragnesia as part of the Dirty Frag vulnerability class. It is not the same bug as Dirty Frag, but it lives in a related attack surface: Linux kernel XFRM ESP-in-TCP.

XFRM is the Linux kernel framework for IPsec processing. ESP-in-TCP is related to carrying ESP encrypted traffic over TCP. Fragnesia comes from logic around shared page fragments and socket buffer coalescing: in some cases, the kernel can lose track of the fact that a fragment is still shared, leaving room for controlled writes.

This resembles the broader Dirty Pipe / Dirty Frag family of page-cache write issues. The concrete code paths differ, but the effect again lands on the page-cache copy of a read-only file.

Why the Risk Is High

Fragnesia is dangerous for three reasons.

First, it is a local privilege escalation. Once an attacker can run ordinary user-level code on a system, they may be able to become root. That matters especially on multi-user servers, container hosts, CI runners, shared development machines, VPS instances, and systems exposing shell access.

Second, it does not rely on a traditional race condition. V12’s notes describe a path that drives ESP-in-TCP processing over file-backed pages already spliced into a socket buffer, allowing byte-level influence over page-cache contents. That makes the issue more practical than a purely theoretical bug.

Third, it changes the page cache, not the on-disk file. The public notes use /usr/bin/su as an example target. After successful exploitation, the file on disk is not permanently modified; the modified copy lives in memory. Integrity checks that only compare disk hashes may miss this.

That is the awkward part for administrators: the file can look unchanged, but executing the polluted page-cache copy of a target binary may still trigger privilege escalation.

Known Affected Scope

V12 Security states that kernels affected by Dirty Frag and missing the relevant May 13, 2026 patches are also affected by Fragnesia. Publicly tested environments include Ubuntu 22.04, Ubuntu 24.04, and kernels such as 6.8.0-111-generic.

There are two important caveats.

First, do not judge only by the distribution major version. Whether Ubuntu 22.04 or 24.04 is affected depends on the actual kernel patch state, not just the distribution name.

Second, do not rely only on default AppArmor restrictions for unprivileged user namespaces. Ubuntu’s AppArmor restrictions can raise the bar, but the disclosure treats that as an additional bypass problem, not as a fix for the vulnerability itself.

The reliable path is still to check distribution security advisories and kernel package updates.

Temporary Mitigation

If a system cannot be upgraded immediately, first check whether it depends on the relevant protocol modules.

V12 gives the same mitigation direction as Dirty Frag: if the system does not depend on IPsec ESP or RxRPC, administrators can consider disabling modules such as esp4, esp6, and rxrpc. This can affect networking features, so production systems should not do it blindly. Confirm whether the environment uses IPsec, VPNs, tunnels, or related kernel functionality.

A safer response order is:

Check whether the distribution has published a kernel security update.
Install the kernel patch and schedule a reboot first.
If immediate upgrade is impossible, evaluate temporary module disabling.
Prioritize multi-user systems and CI / build environments.
Review unnecessary local accounts, shell access, container escape surface, and low-privilege execution entry points.

Disabling modules should not be treated as the final fix. It is only a way to reduce exposure while moving toward a patched kernel.

If Exploitation Is Suspected

One key feature of Fragnesia is page-cache pollution. V12 notes that after exploitation, the target file’s page-cache copy may contain injected content, and later execution can still behave abnormally until the page is evicted or the system is rebooted.

If exploitation is suspected, do at least the following:

Preserve logs and audit records as soon as possible.
Check recent abnormal local logins, low-privilege user activity, suspicious processes, and root shell traces.
Clear the relevant page cache or reboot directly.
Upgrade to a fixed kernel.
Verify key binaries, but do not rely only on disk hashes.
Rotate potentially exposed credentials and keys.

For production servers, it is better to treat this as a potential local privilege escalation incident, not merely as a routine patch event.

Which Machines Should Come First

The highest priority is not every Linux machine equally. Start with systems where attackers are most likely to obtain low-privilege code execution.

High-priority environments include:

Multi-user login servers
CI / CD runners
Build machines
Shared development machines
Container hosts
VPS and cloud servers
Edge nodes exposing SSH
Platforms running third-party scripts or plugins

Closed, single-user machines with no external code execution entry point are still affected if vulnerable, but their urgency is lower.

Summary

Fragnesia matters not because it has a new name, but because it again pulls Linux local privilege escalation back into the difficult boundary between the page cache and kernel networking subsystems.

For administrators, the important work is to confirm kernel patch status, understand whether ESP / RxRPC is in use, prioritize highly exposed machines, and remember that “the disk file is unchanged” does not mean “the system was unaffected.”

If a system is affected, the final answer is still to install the distribution’s kernel update as soon as possible. Temporary module disabling is only a bridge, not a replacement for the patch.