Fragnesia (CVE-2026-46300) — The Linux Kernel LPE That the Dirty Frag Patch Created

Fragnesia (CVE-2026-46300) — The Patch That Introduced the Next Bug

A new Linux kernel local privilege escalation called Fragnesia was publicly disclosed on May 13, 2026, and in an irony that will not be lost on anyone following this month's kernel security incidents: the vulnerability was accidentally introduced by the patch that was meant to fix Dirty Frag (CVE-2026-43284). A working proof-of-concept landed on GitHub the same day the advisory dropped. No race condition. Deterministic. Root on first attempt.

No in-the-wild exploitation has been confirmed at the time of writing, but that gap between "public PoC on GitHub" and "active exploitation" has been measured in hours for every other kernel LPE this month. Treat it accordingly.

What Went Wrong in the Dirty Frag Patch

The Dirty Frag fix modified how the kernel handles socket buffer fragments in the ESP-in-TCP decryption path. The patch correctly blocked the write-into-shared-page-cache primitive for the modules it targeted, but it left a logic gap in skb_try_coalesce() — a function that merges socket buffer fragments for performance.

The specific defect: when skb_try_coalesce() transfers paged fragments from one socket buffer to another, it fails to propagate the SKBFL_SHARED_FRAG marker. This flag tells the kernel that the fragment is backed by a page-cache page — a page that may be shared with userspace and must not be written. Without the flag on the destination buffer, the kernel no longer knows the pages are restricted, and the in-place decryption path proceeds to write into them exactly as it did before the patch.

The primitive that emerges is a 192-byte XOR via AES-GCM keystream applied through TCP coalescing in ESP-in-TCP mode. The attacker controls the plaintext, controls the ciphertext, and therefore controls what gets written into the kernel's page cache of any file they can read — including setuid binaries like /usr/bin/su.

The on-disk binary is not touched. The inode is unchanged. The file's checksum is unchanged. Only the in-memory copy that the kernel serves to execve has been silently rewritten. The next time anything calls /usr/bin/su, it runs the attacker's payload.

Who Found It and How

Fragnesia was discovered by William Bowling of Zellic and the V12 security team, with assistance from Zellic's AI-agentic code-auditing tool. This is the same class of tool — AI-driven, pattern-based kernel analysis — that was used to find Copy Fail. Finding a bug in a code pattern tends to surface the surrounding class of bugs. The Dirty Frag patch, by moving the flaw one function up the call stack rather than eliminating the root class, created a new instance for the same tooling to find.

Who Is Affected

Fragnesia affects all Linux distributions running kernels that include the Dirty Frag partial patch but not yet the Fragnesia fix.

If you are running Ubuntu and applied the Dirty Frag kernel patch this week expecting to be protected, you are protected from Dirty Frag but exposed to Fragnesia until Ubuntu ships the follow-up fix.

Exposure Model

The vulnerability is local privilege escalation. An attacker needs an unprivileged foothold first — a shell account, a compromised application running under a non-root user, a CI/CD runner, or a container with CAP_NET_RAW available. From there, Fragnesia escalates to root in a single command.

High-risk environments:

• Shared hosting — multiple tenants with shell access on the same kernel
• Container hosts — workloads that can access host network namespaces
• CI/CD runners — job code executing as unprivileged users on shared infrastructure
• Multi-user development servers — any system where more than one person has SSH access

Lower-risk but still patch-urgently:

• Single-tenant dedicated servers — the exploit requires local access, but any compromised service (a web app, a queue worker, a cron job) provides that access

Mitigation: Block the Affected Modules

If your distribution has not yet shipped a patched kernel, the following closes the attack surface immediately. Be aware that disabling esp4 and esp6 will break any IPsec VPN using the ESP protocol (StrongSwan, Libreswan, most site-to-site VPNs). Evaluate this against your workload before applying.

# Unload the vulnerable modules immediately
sudo rmmod rxrpc
sudo rmmod esp4
sudo rmmod esp6

# Prevent them from reloading on next boot
sudo printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' >> /etc/modprobe.d/dirtyfrag.conf

# Flush the page cache to clear any in-memory corruption
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

# Verify the modules are no longer loaded
lsmod | grep -E "rxrpc|esp4|esp6"
# Expected: no output

Patch and Reboot: The Only Full Remediation

Module unloading closes the attack vector but does not replace a patched and rebooted kernel. When your distribution ships the fix:

# Debian / Ubuntu
sudo apt update && sudo apt upgrade
sudo reboot

# RHEL / AlmaLinux / CloudLinux
sudo dnf update kernel
sudo reboot

# After reboot — verify running kernel
uname -r

After rebooting into the patched kernel, remove the modprobe denylist entries added above so that IPsec functionality is restored if you need it:

sudo sed -i '/install esp4 /bin/false/d; /install esp6 /bin/false/d; /install rxrpc /bin/false/d' /etc/modprobe.d/dirtyfrag.conf

The Pattern Behind the Pattern

Three Linux kernel LPEs in two weeks — Copy Fail, Dirty Frag, and now Fragnesia — all sharing the same root class: in-place memory operations on pages the kernel does not own. The Dirty Frag patch moved the defect up one function in the call stack. It did not remove the class of bug from the codebase. Fragnesia is the predictable result.

AI-assisted security tooling finds classes of bugs, not individual instances. Every patch that fixes an instance without eliminating the class creates an opportunity for the next tool run to find the remainder. This is the new shape of kernel vulnerability disclosure, and the pace is unlikely to slow. For the full context on how this fits into the broader May 2026 kernel and cPanel security storm, see our May 2026 CVE roundup.

Our team handles kernel patch rollouts and emergency mitigation across managed Linux infrastructure as part of our security and compliance service. If you are not sure which of this month's CVEs your servers are exposed to, get in touch.