Fragnesia (CVE-2026-46300) — the third XFRM LPE in three weeks

TL;DR — the 90-second summary

What is Fragnesia?

A new local Linux kernel privilege escalation (CVE-2026-46300) in the espintcp ULP path. Same XFRM/ESP complex as Dirty Frag — but a separate bug, not a re-announcement.

How serious?

Trivial. An unprivileged local user becomes root in a single command. Public PoC available. No race condition needed — a deterministic write primitive.

Who is affected?

Practically every modern Linux kernel where the modules esp4, esp6 or rxrpc can be auto-loaded. CloudLinux 7h, 8, 9, 10 are affected; AlmaLinux 9 and 10 as well (CL9/CL10 use the AlmaLinux kernel). Ubuntu status across all active kernels: “Needs evaluation”.

What to do — immediately?

Mitigation is identical to Dirty Frag: blacklist esp4, esp6, rxrpc via a /etc/modprobe.d/ entry and unload them. Additionally, drop the page cache because the exploit overwrites system binaries (such as /usr/bin/su) in the page cache — the mitigation alone does not clean those manipulations.

What is different from Dirty Frag?

Three things: (1) The write primitive is deterministic rather than race-based. (2) The exploit modifies arbitrary readable files in the page cache, not just specific structures. (3) Anyone who already has the Dirty Frag mitigation in place (esp modules blocked) is also protected against Fragnesia — the value of class-based mitigation showing itself.

Patch status as of 15 May 2026?

AlmaLinux 9 (5.14.0-611.54.4.el9_7+) and AlmaLinux 10 (6.12.0-124.56.2.el10_1+) are in testing. CloudLinux builds on top of that. KernelCare live patches are out for the CL9 ELS/FIPS variant; more streams follow. Upstream mainline fix: only in the netdev tree, not yet in linus/master. An additional exploit path was identified on 14 May — the distributions are currently building new kernels with the extended fix.

What we did at Moselwal?

Mitigation has been active on all customer hosts since Dirty Frag, so Fragnesia was already blocked. We pushed an additional drop_caches step across the fleet after disclosure. Kernel updates are scheduled as soon as the distros release the extended fix. KernelCare-subscribed inventory receives the live patch automatically.

 

What is the problem?

Fragnesia is a logic flaw in the Linux kernel’s ESP-in-TCP code path — specifically the espintcp ULP, which encapsulates IPsec ESP traffic over TCP streams (RFC 8229). The bug arises from the order of two kernel operations that the kernel incorrectly combines.

The sequence

1. A TCP socket is opened and the unprivileged process splices data into the receive queue via splice(2) or sendfile(2) from any readable file. Importantly, those are real file pages from the page cache — not copies, but direct references.
2. The same socket is then switched into ESP ULP mode via setsockopt(SOL_TCP, TCP_ULP, “espintcp”) — without discarding the already-queued file pages.
3. Inside the ESP ULP path, the kernel treats incoming data as ESP packets with AES-GCM encryption. It therefore begins to interpret the queued file pages as ESP ciphertext and to decrypt them in place.
4. The AES-GCM keystream is XORed against the file pages. Because the attacker controls the IV nonce (part of the synthetic ESP headers), they can predict the keystream byte by byte.
5. Result: a controlled one-byte write into the page cache of any readable file per trigger invocation. Any other process subsequently reading that file sees the manipulated content — including privileged processes executing /usr/bin/su or /usr/bin/sudo.

Why no race condition

Unlike classic page-cache race exploits (Dirty COW 2016, Dirty Pipe 2022), Fragnesia needs no temporal coordination. The write operation is the natural consequence of the kernel’s code path. The attacker steers IV and plaintext selection deterministically — the write primitive lands exactly where they want it.

What the public PoC does

The exploit published by V12 Security writes a 192-byte position-independent ELF stub into the page cache entry of /usr/bin/su. The next su invocation (by the user themselves or another process on the same host) executes that stub as root — in a single command.

Who is affected?

Practically every Linux host running a standard distribution kernel where the esp4, esp6 or rxrpc modules can be auto-loaded. That is the default configuration across virtually every popular distribution.

Confirmed affected (as of 15 May 2026)

• CloudLinux 7h, 8, 9, 10 — every active CL line is affected. CL7 (without “h”) is the only exception because that kernel does not include the ESP ULP.
• AlmaLinux 9 and 10 — the upstream distribution for CL9/CL10. Patched kernels in testing: 5.14.0-611.54.4.el9_7 (AL9) and 6.12.0-124.56.2.el10_1 (AL10), or newer.
• Ubuntu — Canonical has classified the bug as High priority (“trivial local privilege escalation”) and set “Needs evaluation” status across every active kernel package (linux, linux-aws, linux-azure, linux-gcp, linux-oracle, linux-hwe-*, linux-fips, etc.). As of 13 May the fix lives exclusively in the netdev tree, not yet merged into linus/master.
• Debian, RHEL, SLES, etc. — same bug class, same mitigation. Upstream patches are expected within the next few days.

Not affected

• Kernels that did not build ESP-in-TCP — very rare outside hardened embedded systems.
• Already fully patched kernels (distro update after 13 or 14 May 2026, depending on distribution).
• Hosts with the Dirty Frag mitigation already active (modprobe blacklist on esp4/esp6/rxrpc): it covers Fragnesia identically. If you mitigated Dirty Frag you are also protected against Fragnesia — but you must additionally drop the page cache (see Mitigation).

Heightened risk profiles

• Shared-hosting stacks with multiple tenant FE users on one host: every local user becomes root — tenant separation collapses immediately.
• Container hosts with privileged sidecar workloads or mount layouts that give containers write access to the host page cache.
• CI/CD workers executing external (untrusted) code: a single malicious job becomes host root.
• Kubernetes worker nodes running pods with CAP_NET_ADMIN or direct socket access — not required, but the risk rises sharply.

Impact

The impact is almost identical to Dirty Frag and Copy Fail, but the exploitation profile is worse for defenders:

Full host compromise

Any local user becomes root in a single command. All container and tenant boundaries based on user IDs collapse. On shared-hosting platforms, tenant separation is immediately void.

Binary tampering in the page cache

The exploit does not just modify process memory — it overwrites system binaries (such as /usr/bin/su) in the page cache. Once another process reads the file, it sees the tampered content. The effect is persistent for the duration of the boot: only on the next disk read or after drop_caches does the original content come back.

Forensic damage

Standard file integrity tools such as rpm -V, debsums, AIDE or Tripwire read the file through the page cache — and therefore see the tampered stub while the on-disk checksum remains correct. Classic FIM scans will not detect the attack while the page cache is poisoned.

Lower detection probability than Dirty Frag

Unlike race-based exploits, Fragnesia produces no telltale signs such as spinlock pressure, parallel file pounding, or unusual scheduler patterns. The exploit looks like an ordinary TCP connection with a few setsockopt calls — eBPF audit rules that trigger on race symptoms will not fire.

In combination with other CVEs

The “XFRM/ESP logic flaw” bug class has now produced three CVEs in under three weeks. It is statistically likely that further CVEs in this layer will follow — either as independent findings or as variations of the same logic. If you do not need esp4/esp6/rxrpc, blacklist them permanently, not just for this single incident.

Mitigation and immediate actions

Quick start in two commands

If you read nothing else but have to act now:

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"
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

The first command permanently blacklists the three vulnerable kernel modules and unloads them if already present. The second command mandatorily drops the page cache so no potentially poisoned binaries remain in memory.

If you already mitigated Dirty Frag

The first command is identical to the Dirty Frag mitigation. If you already created /etc/modprobe.d/dirtyfrag.conf, Fragnesia is blocked too — the bug class is covered. You still need to drop the page cache because between Dirty Frag disclosure (7 May) and Fragnesia disclosure (13 May) binaries may have been tampered on hosts where the bug was exploited.

Compatibility — who must NOT apply this mitigation

esp4/esp6 are the kernel-side ESP transforms used by IPsec. The mitigation breaks the kernel data path for IPsec on the affected host. Do not apply on:

• VPN gateways terminating IPsec/strongSwan/Libreswan
• Transit routers carrying kernel-mode IPsec tunnels
• Edge hosts with site-to-site IPsec to cloud providers

For these setups the patch path (kernel update + reboot) is the only option. Alternatively: switch to user-space IPsec like strongSwan in kernel=netkey=no mode (rare) or migrate to WireGuard.

rxrpc is the AF_RXRPC transport, used almost exclusively by AFS clients. On typical TYPO3/Sylius hosting servers it is not in use — the blacklist is harmless there.

Drop the page cache, no exceptions

Even if you do not suspect concrete exploit activity on your host: echo 3 > /proc/sys/vm/drop_caches is a cheap, always-safe operation that guarantees all binaries are read fresh from disk on next access. Performance impact: a few seconds of higher I/O when tools start the next time, then back to normal.

Reverting after the patch lands

Once a patched kernel is installed and booted:

sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo reboot   # optional, so esp4/esp6 can load again if needed

If you have no IPsec workload: leave the file in place. The ESP modules are not needed on typical hosts, and the bug class may produce further CVEs.

KernelCare — live patch without reboot

For CloudLinux hosts with a KernelCare subscription: as of 14 May the live patch is available for the ELS/FIPS variant of CL9. Update with:

sudo kcarectl --update
kcarectl --patch-info | grep CVE-2026-46300

Further streams follow in the coming days. KernelCare patches land automatically once released.

Detection and verification

Three lead questions for quick triage

1. Are esp4, esp6 or rxrpc loaded on this host? If yes — and you are not running kernel-mode IPsec — then the host is exposed.
2. Did this host have local unprivileged user accounts with shell access between 7 May (Dirty Frag disclosure) and the mitigation rollout? If yes, assume su/sudo may be tampered in the page cache.
3. Has the page cache been dropped after mitigation? If no, run echo 3 > /proc/sys/vm/drop_caches now.

Quick check: are the modules loaded?

lsmod | grep -E '^esp[46]|^rxrpc'

Empty output = modules not loaded, risk currently low. Output present = modules active, apply mitigation immediately.

Verify the mitigation is actually active

cat /etc/modprobe.d/dirtyfrag.conf 2>/dev/null
lsmod | grep -E '^esp[46]|^rxrpc'   # should be empty
modprobe esp4 2>&1 | head -1     # should return 'modprobe: ERROR: ...'

If all three checks show the expected result (file exists, modules not loaded, manual modprobe fails), the mitigation is effective.

Verify the kernel is patched

uname -r

Compare against the patch status:

• CL9 / AlmaLinux 9: 5.14.0-611.54.4.el9_7 or newer (testing as of 13 May, production promotion pending)
• CL10 / AlmaLinux 10: 6.12.0-124.56.2.el10_1 or newer (testing as of 13 May)
• Note: on 14 May an additional exploit path was identified. New kernel versions with the extended fix are in preparation — the final patched build is still being prepared.

For KernelCare:

kcarectl --patch-info | grep CVE-2026-46300

Match = live patch is in place.

Forensics: were binaries tampered with?

After drop_caches, page cache manipulations are gone — but that also means any forensic traces in the page cache are gone. If you need to investigate an incident, before running drop_caches:

# 1. Memory dump (on hosts with AVML, LiME or kdump)
sudo avml /var/log/memory-fragnesia-pre.dump

# 2. Then drop the page cache
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

# 3. File integrity check with a fresh-read tool
sudo rpm -V coreutils util-linux shadow-utils sudo   # RHEL/CL
sudo debsums -c coreutils util-linux passwd sudo     # Debian/Ubuntu

If you do not need a memory dump, run drop_caches directly — that is the standard path for production hosts without an active investigation.

eBPF / Falco detection

Because of the missing race pattern, classic race-detection rules are ineffective. A more specific rule checks for the unusual sequence splice/sendfile → setsockopt(TCP_ULP, “espintcp”) on the same socket within a short time window:

- rule: fragnesia_espintcp_after_splice
  desc: Detect TCP socket transitioning to espintcp ULP after splice/sendfile
  condition: >
    evt.type = setsockopt and
    evt.arg.optname = SO_TCP_ULP and
    evt.arg.optval contains "espintcp" and
    proc.exepath != "/usr/sbin/strongswan" and
    proc.exepath != "/usr/sbin/charon"
  output: "Fragnesia trigger pattern (user=%user.name proc=%proc.exepath fd=%evt.arg.fd)"
  priority: CRITICAL

The rule is meant as a detection indicator, not the primary defence — the modprobe mitigation remains the primary measure.

Operator recommendation

Operational decision block

Recommendation by setup type

Single-tenant TYPO3 hosting without shell users

Low risk profile. Apply the mitigation defensively, drop the page cache, update the kernel in the next regular maintenance slot. KernelCare is recommended but not an emergency.

Shared hosting with multiple FE users

High risk. Mitigation and page-cache drop now, kernel patch within 24-48h. Until patched, do not allow new user sessions if possible.

Multi-tenant Kubernetes worker nodes

The risk assessment depends on pod security profile. Pods without CAP_NET_ADMIN or without host network access practically cannot trigger Fragnesia — but as soon as a pod breaks out of its container or a malicious container runs, the host can be compromised. Apply the mitigation at worker-node level, plan a cluster-wide rollout.

VPN gateway / IPsec concentrator

Do not apply the mitigation. Go directly down the kernel patch path. Until then: do not stop the VPN service (that would break tenant connectivity), but audit endpoint authentication carefully — anyone allowed to terminate an IPsec tunnel has local socket access and therefore Fragnesia trigger capability.

CI/CD runners

Maximum risk. Every build job is a potential attacker. Mitigation immediately, page-cache drop, then kernel patch. Until the patch is available: replace runners with ephemeral VMs (fresh VM per job), not persistent ones.

Bug class as the long-term answer

Three XFRM/ESP LPEs in three weeks are not a coincidence. The layer is clearly under active scrutiny by external researchers. If you do not need the esp modules in production, blacklist them permanently in your platform baseline — do not mitigate CVE by CVE individually. At Moselwal the blacklist has been part of our NixOS/Ansible platform profile since Dirty Frag. Fragnesia caused no immediate fire drill for our customers — only the drop_caches step was pushed afterwards.

What we actually did at Moselwal

Mitigation was already active (since Dirty Frag)

We rolled the modprobe blacklist for esp4, esp6, rxrpc into our NixOS base profile and our Ansible platform role after Dirty Frag (7 May). The blacklist was therefore active on every customer host as of 8 May. Fragnesia was automatically mitigated alongside — no extra rollout needed on 13 May.

Page-cache drop as the additional step

After disclosure on 13 May, we pushed an additional drop_caches step across every host to invalidate any potentially poisoned page-cache content from the window between 7 May and the mitigation rollout. Operational cost: a few seconds of slightly higher disk-read latency, no service impact.

Kernel update schedule

Once the distributions release the extended fix (status 14 May: “additional exploit path identified”) in stable:

• CL9 + CL10: update from AlmaLinux stable, reboot within 48 hours of production promotion.
• NixOS hosts (own infrastructure): mainline update once in nixpkgs unstable, with a backport in our channel-pinning branch if needed.
• KernelCare hosts: automatic live-patch update, no reboot.

Forensic-lite pass

On hosts with local FE users (shared-hosting stack) we ran a short audit pass: last -F | head -30, journalctl --since "2026-05-07" -p warning, plus rpm -V on privilege binaries after the page-cache drop. No anomalies found — the mitigation was in place before the public PoC went out.

Platform baseline update

The modprobe blacklist stays permanently in the platform profile, not just as a CVE-specific reaction. Customers who need kernel-mode IPsec (currently zero) get a dedicated hardened profile without the blacklist and with a closely controlled patch workflow. We also extended our Falco rule set with the setsockopt(espintcp) detection as a second line of defence.

Conclusion

Fragnesia is the third Linux kernel LPE in three weeks from the same bug class. Anyone who already rolled out the Dirty Frag mitigation is also protected against Fragnesia — they only need to drop the page cache once, to remove any residue from the window before the Dirty Frag rollout. Anyone who has not mitigated yet should do so now: three lines of modprobe config, one drop_caches, done. On typical TYPO3 hosts there is no side effect because ESP-in-TCP is not in production use there.

Structurally, Fragnesia is an indicator that the XFRM/ESP layer in the Linux kernel is under active external audit — statistically further CVEs are likely. Anyone who does not need the modules should blacklist them permanently, not react CVE by CVE. At Moselwal the blacklist has been part of our NixOS/Ansible platform profile since Dirty Frag. Fragnesia therefore caused only the drop_caches step for our customers — nothing more.