Security Advisory: Dirty Frag & Copy Fail 2 – Two New Linux LCE Vulnerabilities

What are these vulnerabilities?

On May 7, 2026, two new Linux kernel local privilege escalation exploits were publicly disclosed:

• Dirty Frag (disclosure, PoC) - Discovered by Hyunwoo Kim (@v4bel). Chains two separate page-cache write primitives: an xfrm-ESP path and an RxRPC path. A deterministic logic bug with no race condition, very high success rate, and no kernel panic on failure. The vulnerability class is a direct descendant of Dirty Pipe and extends the same bug family as Copy Fail.
• Copy Fail 2: Electric Boogaloo (disclosure, PoC) - Exploits the exact same xfrm-ESP page-cache write sink as Dirty Frag, but through the UDP MSG_SPLICE_PAGES path. Same bug class as the original Copy Fail (CVE-2026-31431), different subsystem.

Updated (2026-05-08): AlmaLinux has published fixed kernels to the AlmaLinux 8, 9 and 10 testing repositories. For more information on that see here.

Why all three BlueOnyx versions are affected

We initially assumed that these exploits only affect kernels >= 6.5 because the MSG_SPLICE_PAGES feature for UDP sockets was introduced in mainline Linux 6.5. However, Red Hat, in their infinite wisdom, decided to backport MSG_SPLICE_PAGES for UDP all the way down to the 4.18 kernel on EL8. We verified this empirically on all three platforms:

• 5210R (AlmaLinux 8, kernel 4.18): splice(pipe → UDP) works, xfrm state creation inside a user namespace succeeds, esp4 autoloads. AFFECTED.
• 5211R (AlmaLinux 9, kernel 5.14): Same story. Red Hat backported the feature here too. AFFECTED.
• 5212R (AlmaLinux 10, kernel 6.12): Always was going to be affected - no backport needed. AFFECTED.

Thank you, Red Hat. Backporting a performance optimization feature (>4000 commits) across kernel versions when it opens a new attack surface is certainly a choice. We now have to block kernel modules that were never a security concern before, simply because MSG_SPLICE_PAGES got backported into LTS kernels where it wasn't supposed to exist.

The RxRPC path of Dirty Frag does not apply on AlmaLinux, as the rxrpc.ko module is not shipped. All impact comes through the xfrm-ESP path.

How they work

Both exploits share the same core primitive: they use the kernel's ESP (IPsec) no-COW decryption fast path to corrupt the page cache. From an unprivileged user account:

• Create a user+network namespace (permitted when user namespaces are enabled)
• Inside the namespace, create an xfrm ESP state with ESP-in-UDP encapsulation via ip xfrm state add
• Open a UDP socket with UDP_ENCAP=ESPINUDP
• Splice pages from a readable file (e.g. /etc/passwd or /usr/bin/su) into the UDP socket
• The kernel's ESP input path decrypts in-place on the shared pipe pages, writing controlled data into the page cache without copy-on-write

Dirty Frag's PoC overwrites /usr/bin/su with a 192-byte root shell ELF. Copy Fail 2 injects a passwordless uid-0 user into /etc/passwd.

Our mitigation

We have extended the existing layered mitigation in the swatch RPM (which already handled Copy Fail / CVE-2026-31431) with a new block for these exploits:

• Immediate (no reboot needed): A modprobe.d blacklist (/etc/modprobe.d/blueonyx-cve-lce.conf) that prevents esp4.ko and esp6.ko from loading, even when triggered by netlink from inside a user namespace. The modules are not loaded during normal BlueOnyx operation (no IPsec VPN services are used), so this takes effect instantly.
• Persistent (after reboot): grubby applies modprobe.blacklist=esp4,esp6 to all installed kernels. This survives kernel updates and reboots.

The Active Monitor (swatch) verifies and re-applies both layers every 15 minutes. All mitigations are fully idempotent.

As usual, you can install the updates this way on your BlueOnyx as "root":

dnf clean metadata && dnf update -y

Please note: On Aventurin{e} 6110R, Incus and LXC only the virtualization node needs the update. Prioritize the updates accordingly.

Important caveat about user namespaces

These exploits rely on unprivileged user namespaces, which are required by Incus (our container management platform). We cannot simply disable user namespaces without breaking Incus functionality. The esp4/esp6 module blacklist approach provides full protection without impacting Incus.

What about the previous CVE-2026-31431 mitigation?

The existing Copy Fail mitigation (initcall_blacklist=af_alg_init + eBPF AF_ALG socket filter) does NOT protect against Dirty Frag or Copy Fail 2. Those exploits use xfrm/ESP and UDP sockets, not AF_ALG. Both mitigations are now layered in the swatch RPM: AF_ALG blocked for Copy Fail 1, esp4/esp6 blocked for Dirty Frag / Copy Fail 2.

Verification

We confirmed the impact on all three platforms through empirical testing:

• 5212R, AlmaLinux 10, kernel 6.12: Expected impact confirmed. Modules present and usable from user namespaces.
• 5211R, AlmaLinux 9, kernel 5.14: splice(pipe → UDP) returned success. xfrm ESP state installed inside a user namespace with proper UID mapping returned exit code 0. esp4.ko autoloaded automatically.
• 5210R AlmaLinux 8, kernel 4.18: Same result. splice worked. xfrm state installation succeeded. esp4 autoloaded.

Next Steps

• An updated swatch RPM has been published for BlueOnyx 5212R, 5211R and 5210R. All systems will receive the mitigation automatically via the Active Monitor 's hotfix.sh during the DNF update.
• Watch for future kernel updates from AlmaLinux that may include the upstream fix (commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4 in netdev/net.git). Once backported kernels are available, the modprobe.d blacklist can be removed.
• If you are running IPsec VPN services (strongSwan, LibreSwan) on your BlueOnyx box, do not apply this mitigation - contact us for an alternative approach.

Questions?

If you have any questions or concerns, please reach out via the BlueOnyx Discord, our support system or via the BlueOnyx Mailing-List.