Fragnesia (CVE-2026-46300): The Third Linux Kernel Root Exploit in Three Weeks
Fragnesia (CVE-2026-46300): The Third Linux Kernel Root Exploit in Three Weeks
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Ubuntu 26.04 LTS (Resolute Raccoon): The Most Ambitious Ubuntu LTS in a Decade
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- How to Prevent Ransomware Infection Risks?
- What is the best alternative to Microsoft Office?
Fragnesia (CVE-2026-46300): The Third Linux Kernel Root Exploit in Three Weeks
A new local privilege escalation vulnerability in the Linux kernel’s XFRM ESP-in-TCP subsystem lets any unprivileged local user gain root — reliably, deterministically, and without a race condition. A working public proof-of-concept is already live.
Linux administrators have barely had time to catch their breath. Less than a week after patches shipped for Dirty Frag, researcher William Bowling and the V12 Security team have publicly disclosed a third local-root vulnerability in the Linux kernel in under three weeks. They call it Fragnesia (CVE-2026-46300), and a working proof-of-concept is already published on GitHub.
What Is Fragnesia?
Fragnesia is a local privilege escalation (LPE) vulnerability in the Linux kernel’s XFRM ESP-in-TCP subsystem, which handles IPsec-encrypted traffic tunnelled over TCP. It belongs to the same vulnerability class as Dirty Frag but is a distinct, separate bug — not a re-announcement or variant.
Notably, Fragnesia emerged as an unintended side effect of one of the patches intended to fix Dirty Frag. That Dirty Frag fix exposed a pre-existing coalescing flaw that had been dormant since at least 2013, making it newly exploitable in a useful way.
— CloudLinux Security Advisory, May 13, 2026
The Root Cause: A Forgotten Fragment
The underlying flaw lives in the core socket-buffer code. Specifically, skb_try_coalesce() failed to propagate the SKBFL_SHARED_FRAG marker when transferring paged fragments between socket buffers. As a result, the kernel could “forget” that a fragment was externally backed — for example, by page-cache pages spliced in from a file on disk.
Once the kernel loses track of that shared status, the XFRM ESP-in-TCP receive path proceeds to perform in-place AES-GCM decryption directly over those page-cache pages. This allows an unprivileged process to XOR a chosen keystream into memory that was supposed to be read-only — turning the decryption operation into an arbitrary write primitive against the page cache.
- Call
unshare()to create isolated user and network namespaces, acquiringCAP_NET_ADMINwithin that sandbox — no pre-existing host privileges required. - Establish a specially crafted ESP security association using a known AES-128-GCM key, and build a 256-entry lookup table for byte-by-byte rewrites.
- Splice pages from the target binary —
/usr/bin/su— directly into the TCP socket buffer, then switch to espintcp ULP (upper-layer protocol) mode. - The kernel attempts in-place AES-GCM decryption of the queued data, XORing the keystream directly into the page-cache copy of the file.
- Flip specified bytes precisely: rewrite the first 192 bytes of
suin the page cache into a tiny ELF stub that callssetresuid(0,0,0)and executes/bin/sh. - The next user who runs
sudrops into a root shell. The exploit does not rely on any race condition.
The Stealth Problem: On-Disk File Is Untouched
One of the most operationally dangerous aspects of Fragnesia is its on-disk invisibility. The tampered binary only exists in the kernel’s page cache — the in-memory copy of the file. The actual bytes of /usr/bin/su on disk are never overwritten.
This means conventional file integrity monitors (FIM tools, checksums, auditd file watches) will report the file as clean. The system looks uncompromised. But anyone who runs su until the page cache is flushed or the machine is rebooted will receive a root shell.
If you suspect a system may already have been targeted, do not trust that a reboot is optional. The modified page-cache entry for /usr/bin/su persists until explicitly flushed or the machine restarts. Every invocation of su on a compromised system can re-spawn a root shell.
Affected Systems
| Factor | Detail |
|---|---|
| Kernel versions | All kernels affected by Dirty Frag — effectively any kernel unpatched as of May 13, 2026 |
| Confirmed distros | Ubuntu 22.04, Ubuntu 24.04 (tested on kernel 6.8.0-111-generic); AlmaLinux all supported releases; CloudLinux 7h, 8, 9, 10 |
| Root cause age | Underlying coalescing bug traces back to a 2013 kernel commit (cef401de7be8) |
| Race condition required? | No — exploit is fully deterministic |
| Host-level privileges needed? | No — unprivileged local user only |
| Ubuntu AppArmor impact | Raises the bar slightly; one additional bypass step required, not part of the core vulnerability |
Mitigation: Disable the Vulnerable Modules
The upstream fix was posted to the netdev mailing list on May 13, 2026, but downstream distribution patches are still being built and tested. Until a patched kernel is available for your system, the recommended interim mitigation is to blacklist and unload the three vulnerable kernel modules: esp4, esp6, and rxrpc.
Critically, if you already applied the Dirty Frag mitigation (which targets the same modules), you are already protected from the public Fragnesia proof-of-concept and no further configuration changes are required.
# Blacklist modules and unload any currently loaded sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \ > /etc/modprobe.d/dirtyfrag.conf; \ rmmod esp4 esp6 rxrpc 2>/dev/null; true" # If you suspect the system has already been exploited, # flush the page cache to evict any tampered pages: sync && echo 3 | sudo tee /proc/sys/vm/drop_caches # Or simply reboot.
Blacklisting esp4 and esp6 will break IPsec VPN connections. Blacklisting rxrpc will break Andrew File System (AFS) mounts. Verify no production services depend on these before applying the mitigation.
A Pattern of Rapidly Cascading Kernel Bugs
Security analysts are noting a troubling pattern emerging from this cluster of vulnerabilities. Fixes for complex memory-handling bugs in the kernel are themselves becoming targets for rapid bypass research. Fragnesia did not exist independently — it was uncovered precisely because researchers were scrutinising the code paths touched by Dirty Frag patches.
V12 Security has also disclosed that agentic AI-assisted security research contributed to the discovery process — a detail that signals the pace of kernel vulnerability discovery may not slow any time soon.
The Fragnesia disclosure came with no embargo window: the public proof-of-concept and write-up landed on GitHub and social media simultaneously with the netdev mailing list patch, meaning defenders and attackers received the information at the same time. A public PoC already in the wild substantially lowers the barrier to exploitation.
What Administrators Should Do Now
- Apply the module blacklist immediately (see code block above). If Dirty Frag mitigation is already in place, you are already covered — verify with
lsmod | grep -E 'esp|rxrpc'. - Flush the page cache or reboot any system that may have been targeted before mitigation was applied.
- Do not rely solely on file integrity checks — Fragnesia leaves on-disk files untouched. Monitor for unexpected root shells and unusual
suactivity. - Install patched kernels as soon as your distribution ships them. AlmaLinux has already published testing kernels backporting the upstream skbuff fix. Ubuntu, CloudLinux, and others are actively building patches.
- CloudLinux + KernelCare customers: a livepatch is being prepared and will deploy automatically via the standard update flow once available.
Looking Ahead
Three critical local-root exploits in three weeks — Copy Fail, Dirty Frag, and now Fragnesia — all touching overlapping areas of the Linux networking stack. The candidate Fragnesia patch carries two Fixes: tags: one pointing to the Dirty Frag commit, and one to a 2013 commit that introduced the original coalescing flaw. That history suggests the XFRM/ESP surface area has been fragile for over a decade, and the current wave of scrutiny may not yet be finished.
For now, the priority is clear: apply the mitigation, monitor for exploitation, and install patched kernels the moment your distribution makes them available.
