PatchDay Alert
Analysis · 6 min read · 1,141 words By operations-desk

Fragnesia is the patch you already deployed, bypassed

If you rolled the Dirty Frag kernel update last week and called it done, your fleet is exposed again. Worse, patched hosts may still hand out root shells until you drop the page cache.

Fragnesia is the patch you already deployed, bypassed

Your file-integrity monitor will tell you /usr/bin/su is clean. It will be right. The bytes on disk are untouched. And every su invocation on that host will still spawn a root shell for whoever ran the exploit, because the corruption lives in the page cache, not the inode. Until you drop caches or reboot, patching the kernel doesn’t fix the box.

That’s the operational headline for Fragnesia (CVE-2026-46300), the Linux local privilege escalation William Bowling of V12 Security disclosed yesterday, May 13. It’s the third copyfail-class LPE in two weeks. More importantly for anyone who responded to the last one: it’s a bypass of the Dirty Frag fix you may have just rolled.

What actually changed

Dirty Frag (CVE-2026-43284, May 7) introduced SKBFL_SHARED_FRAG as a guard in esp_input() so the kernel would stop performing in-place AES-GCM decryption over page-cache pages spliced into a socket’s receive queue. The patch closed the hole that let an unprivileged attacker overwrite file-backed memory with attacker-controlled bytes.

Fragnesia is the discovery that skb_try_coalesce(), the routine that merges socket buffers in the TCP path, never got the memo. When two skbs are coalesced before ESP processing sees them, the shared-frag flag is silently dropped. The guard added a week ago doesn’t fire. Same write primitive, same ESP-in-TCP trigger, same root shell.

The Fixes: tag on the upstream commit points to 2013, so the gap has been latent for thirteen years. It only became a usable LPE because the Dirty Frag patch turned SKBFL_SHARED_FRAG into a load-bearing check. Fix one flag, miss the propagation path, ship a sequel.

The PoC dropped the same day, at github.com/v12-security/pocs/tree/main/fragnesia. Build it with gcc, run it, get a root shell. No race, no timing, no shellcode acrobatics. The exploit unshares into a user namespace to pick up CAP_NET_ADMIN, installs a transport-mode ESP-in-TCP SA with a known AES-128-GCM key, and performs 48 deterministic 4-byte writes to lay a 192-byte position-independent ELF stub over the page-cache copy of /usr/bin/su. Next su call, root.

Who is exposed

“Every kernel before May 13” is broadly accurate. The PoC was confirmed on Ubuntu’s stock 6.8.0-111-generic. AlmaLinux, CloudLinux, openSUSE, and Debian advisories treat their respective unpatched kernels as affected without naming a lower cutoff. Kernels built without ESP-in-TCP aren’t reachable by the public PoC, but that’s not the default in any major distribution.

Two operational details matter more than the version sweep:

  • If you applied the module blacklist last week for Dirty Frag, you are already blocked. The mitigation surface is shared.
  • If you patched Dirty Frag via a kernel update but did not blacklist the modules, you are exposed to Fragnesia. A kernel reboot fixed Dirty Frag; it does nothing for the coalescing path.

Container workloads inherit the host kernel. Pods with default security contexts can make the unshare(CLONE_NEWUSER | CLONE_NEWNET) call the PoC requires. Multi-tenant Kubernetes nodes and shared CI runners are the highest-urgency exposures in most fleets. Whether allowPrivilegeEscalation: false or non-root pod UIDs close the path isn’t confirmed yet, so don’t bank on it.

As of May 14, no in-the-wild exploitation has been reported. The CVE is still RESERVED in NVD, so there’s no official CVSS or EPSS yet. The predecessor (Copy Fail, CVE-2026-31431) scored 7.8. Expect similar once it clears, and expect EPSS to climb fast given the public deterministic PoC.

What to do this week

Patch where you can. The upstream fix landed May 13. Distro response so far:

  • Amazon Linux: kernel updates across all maintained branches (4.14 through 6.18) on day zero.
  • AlmaLinux: patched kernels in testing repos same day. CloudLinux with KernelCare is building rebootless live patches, rolling out over 24 to 48 hours.
  • openSUSE: VUL-0 bug 1265209 filed May 13. Tumbleweed typically 24 to 48 hours; Leap on SLE cadence.
  • Ubuntu / Debian: no USN or DSA as of May 14. Plan a kernel reboot within 3 to 5 business days, or use the module workaround in the meantime. Ubuntu’s default kernel.apparmor_restrict_unprivileged_userns=1 partially blocks the unmodified PoC.
  • RHEL / CentOS Stream: no RHSB published yet, consistent with how Red Hat handled the prior two. Next-maintenance-window reboot once errata lands. Module mitigation as a bridge.
  • Oracle Ksplice: no public announcement at time of writing.

If you can’t reboot now, unload and blacklist the three modules the exploit requires. This is identical to the Dirty Frag workaround:

rmmod esp4 esp6 rxrpc 2>/dev/null
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf

Read this part before you paste: esp4 and esp6 are the kernel-mode IPsec transforms. Hosts terminating or transiting IPsec VPN sessions cannot apply this workaround. They need the patched kernel. Check with ip xfrm state and lsmod | grep -E 'esp|rxrpc' first. rxrpc is AFS-only and is safe to disable on essentially every production server.

The cache-residue trap

This is the part most teams will get wrong. The exploit overwrites the page-cache page backing /usr/bin/su, not the file on disk. A file-integrity monitor that hashes the binary by reading filesystem blocks will see a clean file on a compromised host. The cached page is what exec() actually loads, so every su invocation runs the attacker’s stub until that page is evicted.

After you patch or blacklist on any host that was reachable during the exposure window, drop the page cache:

echo 1 | tee /proc/sys/vm/drop_caches

The 1 drops clean page-cache pages only, which is what you need and avoids the overhead of also flushing dentry/inode caches. On a latency-sensitive database, a controlled reboot achieves the same eviction without the cache-cold cliff.

The exposure window opened the moment the PoC was published. If a host was unpatched after May 13 and /usr/bin/su was read into memory while exposed, treat it as potentially residue-contaminated. Drop caches or reboot. Don’t trust the file hash.

The window

The patch path is straightforward and the workaround is something half the fleet already deployed last week. The real cost on most operations teams is auditing which hosts received the Dirty Frag kernel update without the module blacklist, and remembering that golden images, AMIs, and launch templates need rebaking before auto-scaling groups stop spinning up vulnerable nodes from stale templates.

Three copyfail LPEs in two weeks is a pattern, and someone else can write the trend piece. For the team running fleets: assume the next one ships within the month, keep the modprobe blacklist deployed by default on hosts that don’t need IPsec or AFS, and audit your page-cache hygiene playbook now while it’s still cheap. The next bypass will reuse this primitive. The hosts that drop caches reliably after a kernel CVE will be the hosts that don’t have to explain a rooted node to the change board.

If you’d rather not babysit the kernel CVE feed for the fourth one, that’s what PatchDay Alert is for.

Share

Related field notes

One email, every weekday morning.

You're in. Check your inbox.

Get the digest

Free. Weekday mornings. Plain English CVE triage.

Check your inbox to confirm.