Copy Fail Dirty Frag Mitigation: Critical 2026 Linux LPE Fix

Three local privilege-escalation bugs in the Linux kernel arrived within a fortnight of each other in 2026, and all three are especially dangerous on shared hosting, where “local” means any customer with a PHP script or an SSH login. Each depends on a kernel module that almost no hosting server actually uses, which means each can be neutralised in minutes with a modprobe blacklist, well before you schedule the reboot for a fixed kernel.

Short answer: All three flaws depend on kernel modules a hosting server does not use, so write install algif_aead /bin/false, install esp4 /bin/false, install esp6 /bin/false and install rxrpc /bin/false into /etc/modprobe.d/cve-2026-lpe.conf, unload any that are loaded, and run dracut -f so the rule survives a reboot. Add user.max_user_namespaces = 0 to close the usual exploit entry point. Treat this as a bridge until a patched kernel or a KernelCare live patch is in place.

The three flaws

Copy Fail, CVE-2026-31431, was published on 29 April. It abuses the algif_aead interface, part of the userspace crypto API that lets a process drive kernel AEAD ciphers through a socket. A crafted sequence of operations corrupts memory in a way that yields root. Nothing in a typical web, mail or database stack opens an AF_ALG socket.

Dirty Frag covers CVE-2026-43284 and CVE-2026-43500, published 7 May. The flaw sits in the xfrm ESP fragmentation path used by IPsec and in the RxRPC transport used by AFS. It was being exploited in the wild within days. The affected modules are esp4, esp6 and rxrpc; blocking them removes the code path entirely, at the cost of IPsec tunnels and AFS mounts.

Fragnesia, CVE-2026-46300, followed on 13 May and is a bypass of the initial Dirty Frag fix using ESP encapsulated in TCP. It is closed by the same module blocks, which is why blocking rather than patching alone was the right first move.

Check whether the modules are loaded

lsmod | grep -E '^(algif_aead|esp4|esp6|rxrpc|af_alg)'
uname -r

On most hosting servers the grep returns nothing, which means the modules are not loaded right now. That is not protection: they load on demand the moment a process asks for them, and that process can belong to an unprivileged user. The blacklist is what prevents the on-demand load.

Block the modules

The install directive is stronger than blacklist. A plain blacklist line only stops automatic loading by alias; install <module> /bin/false makes any load attempt, automatic or explicit, run /bin/false instead, so it always fails:

cat > /etc/modprobe.d/cve-2026-lpe.conf <<'EOF'
install algif_aead /bin/false
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

If any of those modules is already loaded, unload it. rmmod fails if something holds a reference, which on a hosting server is unlikely:

for m in algif_aead esp4 esp6 rxrpc; do rmmod $m 2>/dev/null; done
lsmod | grep -E '^(algif_aead|esp4|esp6|rxrpc)' || echo "none loaded"

For algif_aead specifically, some distributions build it into the kernel rather than as a module. In that case the modprobe rule does nothing and you need the kernel parameter initcall_blacklist=algif_aead_init on the boot line, which DirectAdmin documented as its own recommended mitigation. Add it with grubby on EL systems and it takes effect on the next boot:

grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

That one does require a reboot, so use the module block as the immediate step and the boot parameter as belt and braces.

Rebuild the initramfs. The modprobe configuration is read from the root filesystem after boot, but the early boot environment has its own copy. Regenerate it so the blocks are present from the first moment:

dracut -f

On Ubuntu and Debian, run update-initramfs -u instead.

What the blocks break

Be honest with yourself about this before applying fleet-wide. Blocking esp4 and esp6 breaks IPsec tunnels, including strongSwan and Libreswan and any VPN concentrator role the server might have. Blocking rxrpc breaks AFS. Blocking algif_aead breaks software that uses the kernel crypto API from userspace, which is rare but includes some cryptsetup configurations and a few storage tools. A shared web server has none of these. A server that terminates a site-to-site VPN does, and it needs the patched kernel rather than the workaround.

Wider hardening while you are there

Two sysctls make the whole class of module-loading exploits harder. kernel.modules_disabled = 1 stops any further module loading until reboot, which is safe once everything the server needs is loaded (check CSF’s needs first, see CSF on AlmaLinux 10). user.max_user_namespaces = 0 removes unprivileged user namespaces, which most of the 2026 exploit chains used to reach the vulnerable code:

cat > /etc/sysctl.d/99-lpe-hardening.conf <<'EOF'
user.max_user_namespaces = 0
EOF
sysctl --system
sysctl -w kernel.modules_disabled=1

modules_disabled is deliberately not in the file: it is a one-way switch that cannot be reverted without a reboot, so set it from a script late in boot rather than from sysctl.d, after every module the server needs has loaded. Note that disabling user namespaces breaks rootless containers, which matters on cPanel 138 hosts using the Podman-based Node.js toolkit.

Patch properly

The blocks are a bridge. The real fix is a kernel with the patches, applied either by a reboot into the updated package or by a live patch. KernelCare shipped patches for all three within days; see our KernelCare guide for kcarectl --update and how to prove the patch is active. After patching, clear the page cache once so any exploit primitive that relied on cached pages loses its footing:

sync; echo 3 > /proc/sys/vm/drop_caches

Verify

Prove that a load attempt fails, that the boot image carries the rule, and that the namespaces sysctl stuck:

modprobe esp4; echo "exit: $?"
lsinitrd 2>/dev/null | grep -c cve-2026-lpe.conf
sysctl user.max_user_namespaces

The modprobe exit code should be non-zero, the initrd should contain the file, and the sysctl should read zero. A common pitfall is applying the blacklist and forgetting dracut -f; the server is protected until the next reboot, after which the early-boot module loader ignores the rule for anything loaded before the root filesystem is mounted. Keep the check in your post-reboot runbook until every server in the fleet is on a patched kernel.

Copy Fail Dirty Frag mitigation at a glance

Official documentation: AlmaLinux wiki, Linux man pages.

Related guides: Installing Sentinel Firewall as a drop-in CSF replacement on Ubuntu 24.04 and Debian 13 · Replacing CSF with firewalld + fail2ban on AlmaLinux 9/10, step by step · CVE-2026-65638, 65639 and 67402 explained: patching the CSF Messenger and URLGET remote-code flaws.

Frequently asked questions