Fragnesia Flaw Enables Local Root via Linux Page Cache Corruption

CVE-2026-46300 allows local root escalation on Linux by corrupting read-only files in memory. With a public PoC available and patches still under review, mitig…

Fragnesia Flaw Enables Local Root via Linux Page Cache Corruption

On May 13, 2026, V12 researcher William Bowling disclosed "Fragnesia" (CVE-2026-46300), a Local Privilege Escalation (LPE) vulnerability in the Linux kernel. The flaw allows unprivileged local attackers to gain root access by deterministically corrupting the page cache of read-only system files, such as /usr/bin/su, while they reside in memory.

A public proof-of-concept (PoC) has been released, while a candidate patch is currently awaiting review on the netdev mailing list, leaving many systems exposed until a stable release is finalized. The discovery is particularly critical because the same mitigations used to counter the "Dirty Frag" vulnerability—blacklisting the esp4, esp6, and rxrpc modules—also block this attack, confirming that emergency corrections in this attack surface can reveal latent bugs.

Key Takeaways
  • CVE-2026-46300 enables deterministic root escalation by corrupting the RAM-based page cache of read-only files (e.g., /usr/bin/su) without altering disk content or requiring race conditions.
  • The bug resides in skb_try_coalesce(), where the loss of the SKBFL_SHARED_FRAG marker allows in-place AES-GCM decryption on shared page cache pages, turning a network operation into a kernel memory write primitive.
  • V12's public PoC utilizes a lookup table of nearly 256 nonces to achieve a byte-per-byte write primitive in the page cache, injecting a ~192-byte ELF stub.
  • Dirty Frag mitigations (blacklisting esp4, esp6, and rxrpc) effectively block Fragnesia; AlmaLinux has already released patched kernels in testing repositories for versions 8, 9, and 10.

From Dirty Frag to Fragnesia: The Risks of Emergency Patching

Carrying a CVSS score of approximately 7.8, Fragnesia is the third LPE vulnerability to emerge in less than two weeks within the XFRM ESP-in-TCP / rxrpc subsystem. This represents an unusual density of critical flaws in a kernel area previously considered marginal.

Bowling identified a logic bug latent since 2013, which was rendered exploitable by the very patch intended to fix Dirty Frag just days earlier. The candidate patch for Fragnesia explicitly includes two "Fixes" tags: one for the Dirty Frag commit (f4c50a4034e6) and another for a 2013 commit (cef401de7be8), confirming that the previous mitigation altered code conditions without fully closing the attack surface.

Technical Analysis: How skb_try_coalesce() Fails to Protect the Page Cache

The technical core of Fragnesia lies in socket buffer management. During coalescing, the skb_try_coalesce() function transfers paged fragments between buffers but fails to propagate the SKBFL_SHARED_FRAG marker—a flag indicating that the fragment is shared externally, such as with the page cache of a read-only file.

"The underlying flaw is in the core socket-buffer code: skb_try_coalesce() failed to propagate the SKBFL_SHARED_FRAG marker when transferring paged fragments between buffers, so the kernel could lose track of the fact that a fragment was externally backed" — AlmaLinux Blog

When the XFRM ESP-in-TCP subsystem performs in-place AES-GCM decryption, the kernel no longer recognizes the shared nature of the page and writes directly into the page cache memory. This error transforms a legitimate network operation into a deterministic write primitive against protected kernel memory regions.

The V12 Exploit: Write Primitives and Cache Persistence

The public exploit released by V12 leverages the missing marker to build a lookup table of nearly 256 AES-GCM nonces, gaining a byte-per-byte write primitive within the page cache of read-only binaries.

The payload consists of a ~192-byte ELF stub that, once loaded into memory, executes calls such as setresuid(0,0,0) to spawn a root shell. Because the modification only affects the RAM-based page cache, the on-disk binary and its cryptographic hashes remain unchanged. However, the corrupted cache persists until it is evicted or the system is rebooted.

This ensures the compromise remains stable across successive invocations of the binary without needing a race condition. It poses an immediate threat to multi-tenant environments where a local user can corrupt binaries shared across the system.

Upstream Status and Distribution Response

At the time of disclosure on May 13, 2026, Bowling's proposed patch on the netdev mailing list was still awaiting review and had not been merged into the upstream tree. While there are currently no reports of exploitation in-the-wild beyond the public PoC, the lack of specific indicators does not rule out risks in high-exposure environments.

Microsoft and CloudLinux have confirmed that environments already applying Dirty Frag mitigations do not require additional action until a patched kernel is installed. For operations teams, the need for a second mitigation cycle in the same attack surface within two weeks underscores the strain on infrastructures that cannot support frequent reboots.

AlmaLinux has moved ahead of CentOS Stream and RHEL by publishing corrected builds in testing repositories for releases 8, 9, and 10. These are identified as kernel-4.18.0-553.124.2.el8_10 and later, kernel-5.14.0-611.54.4.el9_7 and later, and kernel-6.12.0-124.56.2.el10_1 and later. It is not yet known if other distributions have finalized stable packages; Red Hat is currently evaluating the effectiveness of existing mitigations.

Remediation and Mitigation Strategy

  • Immediate Module Blacklisting: If not already implemented, blacklist the esp4, esp6, and rxrpc kernel modules via modprobe or configuration files in /etc/modprobe.d. This is the same mitigation used for Dirty Frag and effectively neutralizes the Fragnesia attack vector before it reaches skb_try_coalesce().
  • Restrict Local Attack Surface: In multi-tenant environments, such as CI runners and container hosts, limit local shell access and restrict unprivileged user namespaces via AppArmor or kernel parameters. Note that this is a partial defense and does not replace module blacklisting.
  • Plan Kernel Updates: Monitor distribution repositories for stable updates. Consider adopting testing builds from downstream vendors like AlmaLinux where appropriate. A patched kernel remains the only permanent solution.
  • Verify Critical Binary Integrity: On suspected systems, force a page cache flush via reboot or eviction operations. Since the corruption persists in RAM, it can survive between invocations of the target binary even if the disk content is valid.

The Fragnesia case confirms that interdependencies between socket buffer management and shared memory in the Linux kernel remain difficult to isolate. For operations teams, the message is clear: emergency mitigations are temporary stopgaps. The XFRM ESP-in-TCP subsystem has proven to harbor a chain of latent bugs that rapid patching can inadvertently expose.

Frequently Asked Questions

Does page cache corruption persist on disk?

No. The exploit alters the page cache in memory only. On-disk content and hashes remain intact. The compromise persists only until the cache is evicted or the system reboots.

Why does the Dirty Frag mitigation work for Fragnesia?

Both vulnerabilities exploit the same XFRM ESP-in-TCP subsystem and the same kernel modules (esp4, esp6, rxrpc). Disabling these modules breaks the attack chain before it reaches the flawed code in skb_try_coalesce().

How can I detect if a system has been compromised?

There are currently no specific indicators of compromise (IoCs) beyond the public PoC. Because the page cache corruption is volatile and may leave no trace on disk, detection must rely primarily on behavioral analysis.

Information verified against cited sources and accurate at the time of publication.

Sources