Fragnesia (CVE-2026-46300): A New Linux Kernel LPE in the Dirty Frag Family

The Short Version

What: A flaw in the Linux kernel’s XFRM ESP-in-TCP handling allows an unprivileged local user to induce controlled modifications to cached pages belonging to read-only files, including setuid binaries.

Impact: Local privilege escalation to root through page-cache modification. The on-disk file remains untouched while the in-memory cached copy is altered.

Affected systems: Systems running the affected skbuff code paths, including kernels that already received the Dirty Frag fix. The public PoC requires CONFIG_INET_ESPINTCP to reach the bug, so kernels built without it block this exploit; the underlying skbuff defect, however, may be reachable through other paths. Distros that restrict unprivileged user namespaces by default (such as Ubuntu’s AppArmor configuration) partially block the public PoC.

Exploit status: Public PoC released on GitHub immediately after disclosure.

CVE ID: CVE-2026-46300

Mitigation: Disable vulnerable ESP modules or apply vendor/live patches once available.

KernelCare coverage status (updated 2026-05-18, 13:00 UTC): Rebootless patches are available in main + ePortal feeds for AlmaLinux ELS/FIPS, Debian 11, Debian 12, EL8 family, Rocky Linux 10, Oracle Linux 8, Oracle Linux 8 UEK 7, Oracle Linux 9, Oracle Linux 9 UEK 7, Ubuntu 22.04 (Jammy), Ubuntu 24.04 (Noble).

kcarectl --update # pulls the patch if your kernel is in scope
kcarectl --patch-info | grep cve-2026-46300

Disclosure state: Technical details, affected-version guidance, and mitigation recommendations may evolve as vendors publish advisories and downstream kernel maintainers complete backports.

Five days ago, Linux shipped fixes for Dirty Frag. Today, defenders are dealing with another exploit in the same neighborhood.

Fragnesia (CVE-2026-46300) is a newly disclosed local privilege escalation vulnerability targeting the Linux kernel’s XFRM ESP-in-TCP subsystem. It was published publicly today by William Bowling, working with the V12 Security team, alongside a working proof-of-concept that overwrites /usr/bin/su through the page cache and yields root access.

The disclosure landed publicly on GitHub and X immediately after the netdev mailing list patch appeared, with no embargo window. At publication time, no CVE has been assigned, and the candidate upstream fix is on netdev awaiting review and merge.

What makes Fragnesia notable is not just the exploit itself, but the timing and lineage. The candidate follow-up patch (submitted by Bowling) explicitly cites the Dirty Frag fix (f4c50a4034e6) as one of two commits it “fixes” – meaning the original Dirty Frag remediation exposed a previously latent bug in a way that became practically exploitable. Per Wiz’s writeup, Hyunwoo Kim (the original Dirty Frag reporter) has also acknowledged Fragnesia emerged as an unintended side effect of the Dirty Frag patches.

The broader story is uncomfortable: defenders are now patching the same attack surface twice in less than a week, while exploit developers are iterating nearly as quickly as fixes land.

Why Fragnesia Matters

Fragnesia is not a totally separate bug class from Dirty Frag. It is another exploit path through the same ESP/XFRM attack surface, and the original upstream Dirty Frag fix does not fully stop it.

The technical issue lives in skb_try_coalesce(). When that function attaches paged fragments from one sk_buff into another, it currently drops the SKBFL_SHARED_FRAG marker, even when the resulting buffer still contains externally-owned or page-cache-backed fragments. That breaks the invariant ESP input handling relies on – specifically, the skb_has_shared_frag() check that decides whether an uncloned nonlinear skb can skip skb_cow_data(). Skip the copy-on-write, and you get in-place decryption directly into the shared page.

In other words, the Dirty Frag fix (f4c50a4034e6) added code that trusts the shared-frag marker to be accurate. The marker isn’t accurate. The candidate Fragnesia patch carries two Fixes: tags – one for the Dirty Frag commit, and one for a much older 2013 commit (cef401de7be8) – which tells you the underlying coalescing bug has existed for years. The Dirty Frag fix just made it exploitable in a useful way.

In practice, the exploit achieves the same outcome defenders were already worried about last week: page-cache modification of privileged binaries without touching the underlying file on disk.

If you already deployed the Dirty Frag mitigation that disabled esp4, esp6, and rxrpc, you are already protected from the public Fragnesia PoC. If you only applied the initial upstream fix, you are not.

That distinction matters operationally because it reinforces a pattern defenders are increasingly seeing in modern kernel exploitation: fixes for complex memory-handling bugs are themselves becoming targets for rapid bypass research.

How the Exploit Works

At a high level, the exploit works like this:

1. The attacker creates a new user and network namespace using unshare(CLONE_NEWUSER | CLONE_NEWNET) to obtain CAP_NET_ADMIN inside the sandboxed namespace.
2. A transport-mode ESP-in-TCP security association is installed through NETLINK_XFRM using AES-128-GCM with a known key.
3. The exploit prepares a 256-entry keystream lookup table using AF_ALG crypto interfaces, mapping every possible byte value to a corresponding nonce.
4. File-backed pages are queued into a TCP stream using splice().
5. The socket is switched into espintcp ULP mode after the pages are already queued.
6. Because skb_try_coalesce() previously stripped the shared-fragment marker, the kernel proceeds with in-place AES-GCM decryption directly on the shared cached pages.
7. The chosen keystream byte XORs into the target page, producing a controlled single-byte write. Repeat per byte until the payload is written.

The public PoC overwrites the cached copy of

/usr/bin/su with a small position-independent ELF payload that executes:

setresuid(0,0,0);

execve("/bin/sh");

The exploit is notable because it does not rely on a narrow race window that must succeed exactly once. The attacker repeatedly drives the write primitive until the desired bytes land successfully, making the process far more deterministic than many historical kernel race-condition exploits.

The modified cached page can persist until eviction or reboot, meaning repeated invocations of the targeted binary can continue yielding root access even though the on-disk file hash remains unchanged.

Who Is Most Exposed?

The highest-risk environments are systems that combine:

• untrusted local code execution,
• enabled unprivileged namespaces,
• multi-tenant workloads,
• and active XFRM/ESP kernel support.

That makes the following environments particularly important to prioritize:

• Kubernetes worker nodes
• Shared CI/CD runners
• Shared hosting platforms
• Bastion and jump hosts
• Developer workstations
• Multi-tenant container infrastructure

For these systems, a “local” privilege escalation vulnerability is rarely just local anymore. A compromised container, malicious CI job, stolen SSH key, or application RCE can all become stepping stones to full host compromise.

Rebootless Patching Fragnesia with KernelCare

For the systems flagged above – multi-tenant Kubernetes nodes, shared CI runners, bastion hosts – the practical question is how fast you can actually deploy a fix. TuxCare’s rebootless patching tool, KernelCare, shipped rebootless patches for the EL8 kernel family within 24 hours of the Dirty Frag disclosure last week, ahead of the corresponding vendor erratas. EL9, Ubuntu, Debian, and Proxmox VE followed on the same release wave. That’s the benchmark for what “fast” looks like in this severity class.

For Fragnesia, the cycle is going to be slightly messier. The upstream fix is still on netdev awaiting review, which means the first KernelCare patch will be built against a candidate. If the maintainer-merged version ends up different, expect a rebuild. And because that candidate patch carries a Fixes: tag pointing at a 2013 commit, more skb_try_coalesce() auditing is likely – the first rebootless patch out the door may not be the last one for this attack surface.

That cadence is exactly the case for rebootless patching. Two patches in five days for the same subsystem, both with public PoCs before vendor erratas could catch up, and a third one plausibly coming. The alternative – which the next section walks through – is module blacklisting, namespace restrictions, and an unscheduled rolling reboot once your distro ships a kernel package. Kubernetes nodes drained twice in a week. CI runners cycled mid-build. Bastion failovers nobody scheduled.

One honest caveat: some vulnerability scanners will keep flagging the unpatched kernel package version after live patching, because scanner detection logic trails the actual running-kernel state. The kernel is protected. Your dashboard may not agree for a day or two. Plan ticket-explanation accordingly.

If you’re not on KernelCare and this week broke your patching cadence, it’s a reasonable time to look. New-customer pricing is discounted through the end of June. Get KernelCare → 

Mitigation

Immediate mitigation

The same module blacklist used for Dirty Frag also blocks the public Fragnesia exploit:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

If /etc/modprobe.d/dirtyfrag.conf is already present from previous mitigation work, you can leave it in place.

Operational warning

Disabling esp4 and esp6 breaks IPsec and ESP-based VPN functionality, including deployments using strongSwan or Libreswan. WireGuard deployments are unaffected.

rxrpc is associated with AFS clients and is generally safe to disable on typical servers.

Validate operational dependencies before deploying these mitigations broadly.

Restrict unprivileged user namespaces

Ubuntu systems partially resist the public PoC because AppArmor restricts unprivileged user namespaces by default. The PoC itself instructs users to disable:

kernel.apparmor_restrict_unprivileged_userns=0

before exploitation.

RHEL-family systems can approximate similar protection with:

echo "user.max_user_namespaces=0" > /etc/sysctl.d/fragnesia.conf

sysctl --system

This is only a partial mitigation. It also breaks rootless containers, Flatpak, sandboxed browsers, and other namespace-dependent tooling.

Flush poisoned page cache

Because the exploit modifies only cached pages, systems suspected of compromise should flush page cache contents after mitigation:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

This removes the immediate page-cache persistence, but it does not guarantee the attacker failed to establish more durable persistence afterward. Any successful exploitation should be treated as full host compromise.

Apply vendor fixes

Apply vendor-provided kernel updates or validated live patches once available for your distribution.

At the time of publication, William Bowling’s candidate follow-up patch:

[PATCH net] net: skbuff: preserve shared-frag marker during coalescing

is on the netdev mailing list awaiting review. The patch is small – two lines in skb_try_coalesce() that preserve the SKBFL_SHARED_FRAG flag when transferring fragment descriptors. Maintainers will likely merge a version of this quickly, but downstream backports across distributions take longer.

That matters because defenders may need to treat this as an evolving patch cycle rather than a single remediation event. The two Fixes: tags on the patch suggest broader audit work in the skb coalescing path is warranted.

Detection Guidance

Traditional file-integrity tooling is poorly suited for this class of attack:

• On-disk hashes remain correct
• AIDE and Tripwire may report no modification
• The malicious change disappears after cache eviction or reboot

Behavioral detection is far more promising.

Potential signals include:

• unshare(CLONE_NEWUSER | CLONE_NEWNET) from unexpected processes
• NETLINK_XFRM activity from workloads unrelated to VPN functionality
• Unusually heavy AF_ALG crypto interface use, especially in tight loops
• splice() operations from regular files into TCP sockets followed by ULP changes on the same socket

None of these are inherently malicious independently, but the combination is suspicious enough to justify runtime-detection rules using eBPF tooling, Falco, Tetragon, or Linux EDR platforms.

The Bigger Pattern

Recent Linux privilege-escalation research has repeatedly converged on page-cache corruption, shared-memory ownership, and in-place processing bugs, including:

• Dirty Pipe (2022)
• Copy Fail (2026)
• Dirty Frag (2026)
• Fragnesia (2026)

Three of those surfaced within just a few weeks.

The common theme is increasingly clear: highly optimized kernel paths involving shared memory ownership, page handling, and in-place processing continue producing dangerous write primitives when edge-case assumptions fail.

splice(), skb coalescing, ESP processing, and page-cache interactions are all performance-oriented subsystems. Attackers are increasingly proving that those optimizations can become reliable privilege-escalation paths when ownership semantics break down.

Fragnesia is also notable for how quickly it appeared after the original Dirty Frag fixes landed. V12 Security attributes part of the discovery process to agentic AI-assisted security tooling, and regardless of how much weight you give that claim, the cadence of exploit iteration is accelerating. The fact that the candidate fix carries a Fixes: tag pointing at a 2013 commit also suggests the bug class isn’t exhausted – there are probably more invariant violations in the same code path waiting to be found.

Defenders should assume this bug class is not finished evolving.

Summary

Article Name

Fragnesia (CVE-2026-46300): New Linux LPE That Bypasses the Dirty Frag Patch

Description

Fragnesia (CVE-2026-46300) is a new Linux kernel LPE extending the Dirty Frag family (CVE-2026-43284, CVE-2026-43500).

Author

Tim Walker

Publisher Name

TuxCare

Publisher Logo