By ByteBot
The Dirty Frag patch landed. Sysadmins did the right thing and patched their kernels. They are now running Fragnesia — a new Linux local privilege escalation exploit that the Dirty Frag fix itself activated. CVE-2026-46300, disclosed May 13–14, gives unprivileged local users a deterministic path to root on every major Linux distribution. A public proof-of-concept is already on GitHub.
What Fragnesia Is
Fragnesia lives in the Linux kernel’s XFRM ESP-in-TCP subsystem — the same neighborhood as Dirty Frag. William Bowling of the V12 security team found it with help from an AI-agentic auditing tool. The flaw is in skb_try_coalesce(), which drops the SKBFL_SHARED_FRAG marker when transferring paged fragments between buffers. That marker tells the kernel not to perform in-place decryption on page-cache-backed memory. Without it, the kernel happily performs AES-GCM decryption directly into read-only cached pages.
The attack sequence: create unprivileged user and network namespaces, install an ESP-in-TCP security association via NETLINK_XFRM, queue file-backed pages into a TCP stream using splice(), then flip the socket into espintcp mode. The kernel overwrites whatever file you spliced in — the public PoC targets /usr/bin/su and drops a root shell. CVSS score: 7.8.
No race condition. Deterministic. And here’s the part that makes file-integrity monitoring useless: the attack only modifies the in-memory page cache. On-disk hashes stay clean. Tripwire won’t find it. Neither will most SIEM rules looking for file changes.
How the Dirty Frag Patch Activated It
This is the part that stings. The upstream Fragnesia patch explicitly cites the Dirty Frag fix commit as one of two commits it “fixes.” Hyunwoo Kim, who discovered Dirty Frag, confirmed that Fragnesia “surfaced as an unintended side effect of patches shipped to fix the original Dirty Frag vulnerabilities.”
Any kernel that received the Dirty Frag fix between May 7 and May 13 is now exposed to Fragnesia. You fixed one root exploit and activated another. The module blacklist mitigation covers both — but only if you knew Fragnesia existed, which, until this week, you didn’t. We covered Dirty Frag when it first landed; this is its unintended sequel.
Who’s Actually at Risk
Fragnesia requires local access, making it a post-compromise escalation tool rather than an initial vector. That framing undersells the risk. In practice, “local access” in 2026 means:
- Container clusters and Kubernetes nodes — rootless Docker and Podman users can create unprivileged namespaces, which is all the exploit needs. A compromised containerized application becomes full host root.
- CI/CD runners — shared runners executing untrusted code are prime targets. A malicious dependency in your pipeline can escalate from the runner’s user to root on the host.
- Shared Linux hosts and VPS environments — multi-tenant systems where multiple users have shell access.
- Bastion and jump hosts — a stolen SSH key gets you in; Fragnesia gets you root.
Single-user workstations and single-tenant servers are lower priority. If you run shared infrastructure of any kind, this is immediate-action territory.
Three Linux Kernel LPEs in Fourteen Days
Copy Fail (CVE-2026-31431) disclosed around May 3. Dirty Frag (CVE-2026-43284/43500) on May 7–10. Fragnesia (CVE-2026-46300) on May 13–14. All three exploit the same page-cache corruption primitive in adjacent Linux kernel subsystems. The Register quoted Wiz putting it plainly: “The Linux networking stack is starting to look less like infrastructure and more like a root exploit vending machine.”
Three deterministic, race-condition-free LPEs in two weeks from one corner of the kernel is not coincidence. It points to the XFRM subsystem and its interaction with the page cache not receiving sufficient security review as a cohesive attack surface.
What To Do Now
The immediate mitigation — no reboot required — is blacklisting the vulnerable modules:
sudo sh -c "printf 'install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'Skip this if your workload relies on IPsec ESP tunnels or AFS — you’ll break connectivity. For most servers, it’s safe and effective.
Vendor kernel patches are landing. AlmaLinux has testing builds available now (AL8: kernel-4.18.0-553.124.3.el8_10; AL9: kernel-5.14.0-611.54.5.el9_7; AL10: kernel-6.12.0-124.56.3.el10_1). CloudLinux 9 has rebootless KernelCare patches in its testing feed. The upstream fix is pending netdev review, so other distros will follow within days.
For detection: standard file-integrity tools will miss this entirely. Use eBPF-based behavioral monitoring — Falco or Tetragon — and watch for unshare() calls, NETLINK_XFRM socket activity, AF_ALG usage, and unusual splice() patterns appearing together. That combination is the tell.
Three bugs in fourteen days. The XFRM subsystem has become the most productive attack surface in the Linux kernel right now. Blacklist the modules, watch for patches, and check your detection stack — because the files on disk are going to look perfectly fine.
