Copy Fail: The Linux Kernel Flaw That Gives Anyone Root

This one is different from the PackageKit flaw we covered last week. That was a daemon you could disable. This one lives in the kernel itself — and it's been there since 2017.

CVE-2026-31431, dubbed Copy Fail, is a logic flaw in the Linux kernel's cryptographic subsystem that lets a local unprivileged user gain full root access. A 732-byte Python script. 100% reliability in testing. Every major distribution affected. If you're running Linux — desktop, server, cloud, container — you need to read this.

// what the bug actually does

The flaw lives in the authenc template inside the kernel's crypto processing pipeline. The attack combines two standard Linux interfaces: AF_ALG, which exposes kernel cryptographic functions to userspace, and splice(), which is normally used for efficient data transfer between file descriptors.

Under normal conditions those two interfaces have no business interacting the way this exploit makes them interact. The result is a controlled 4-byte write into the page cache of any readable file. Four bytes sounds small. Point those four bytes at a setuid-root binary and you control what that binary does. From there the path to root is straightforward.

// where it came from

The root cause is a performance optimization introduced in kernel 4.14 in 2017. The change allowed in-place buffer reuse in the crypto pipeline — instead of maintaining separate input and output buffers, the kernel reused the same buffer. Faster, leaner, and quietly broken for nine years.

The Linux kernel maintainers fixed it by reverting that optimization entirely, restoring separate buffer handling. The fix is clean but it took a decade to find the problem.

// how it was found

Theori, an offensive security firm, found it using their AI-assisted penetration testing platform Xint Code. Automated analysis of the kernel's cryptographic subsystem. Total time from start to discovery: approximately one hour.

Disclosed to the kernel security team March 23, 2026. Patched within a week. Public proof-of-concept released shortly after, which is why this is urgent now rather than theoretical.

This is the second major CVE disclosure in two weeks where an AI platform was credited as part of the discovery workflow. The pattern is real. Automated tools are compressing vulnerability research timelines from weeks to hours — which means the gap between patch availability and active exploitation is shrinking on both sides.

// who is affected

Theori confirmed successful exploitation against Ubuntu 24.04 LTS, Amazon Linux 2023, Red Hat Enterprise Linux 10.1, SUSE Linux Enterprise 16, and Debian. Their claim is that any Linux distribution shipping kernel 4.14 or later is potentially affected — which covers essentially everything released since late 2017.

High-risk environments that should treat this as a P1:

Multi-tenant servers, Kubernetes clusters, CI/CD pipelines, and any cloud environment executing user-provided code. In those contexts a low-privileged user hitting root can mean full infrastructure compromise or lateral movement across workloads.

// how it compares to dirty pipe

CVE-2022-0847, Dirty Pipe, used a similar mechanism — unauthorized page cache modification to escalate privileges. Copy Fail is a direct evolutionary step beyond it. Dirty Pipe had kernel version constraints and required specific patching states. Copy Fail spans a decade of kernels, requires no complex offsets or environment tuning, and achieved 100% reliability versus Dirty Pipe's more conditional success rate.

If you patched Dirty Pipe and moved on, that mental model doesn't transfer here. This is broader.

// check, mitigate, verify, patch

Work through this in order. Don't skip to patch without confirming your exposure first.

Step 1 — Check your kernel version

uname -r

If the output is below 6.18.22, 6.19.12, or 7.0, you are running a vulnerable kernel. Note your current version before you do anything else.

Step 2 — Check if the vulnerable module is loaded

lsmod | grep algif_aead

If this returns output, the attack interface is active on your system right now.

Step 3 — Apply the temporary mitigation

This blocks the attack vector by preventing AF_ALG socket creation for the affected crypto interface. It is not a fix — it buys you time to patch.

# Block the module from loading on next boot
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

# Remove it from the running kernel immediately
rmmod algif_aead

Step 4 — Verify the mitigation took effect

# Confirm module is no longer loaded
lsmod | grep algif_aead

# Confirm the modprobe rule is in place
cat /etc/modprobe.d/disable-algif.conf

lsmod should return nothing. The conf file should show install algif_aead /bin/false. If either check fails, the mitigation did not apply correctly — do not proceed assuming you are protected.

Step 5 — Patch the kernel

# RHEL / Rocky Linux
sudo dnf update kernel
sudo reboot

# Debian / Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic
sudo reboot

Step 6 — Confirm patched kernel is running after reboot

uname -r

Output should reflect the patched version. If it doesn't, your bootloader may still be loading the old kernel — check grub configuration and confirm the default boot entry.

Step 7 — Remove the temporary mitigation after patching

Once you've confirmed the patched kernel is running, clean up the workaround:

rm /etc/modprobe.d/disable-algif.conf
sudo dracut -f  # RHEL/Rocky — rebuild initramfs
# or
sudo update-initramfs -u  # Debian/Ubuntu

// a note on advisories

Some distributions have already pushed patched kernels without publishing formal advisories that reference CVE-2026-31431 by name. If you're waiting on a Red Hat Security Advisory or Ubuntu USN before acting, you may be waiting longer than the risk warrants. Check for kernel updates directly and don't gate your patching on advisory publication.

// the takeaway

Copy Fail is a kernel-level privilege escalation with near-perfect reliability, a public proof-of-concept, and a nine-year exposure window. The mitigation is a one-liner. The patch is a kernel update and a reboot. Neither is complicated.

The question isn't whether this is serious. It is. The question is how fast you can work through the six steps above and confirm your systems are no longer running the vulnerable interface.

Check. Mitigate. Verify. Patch. Confirm.

In that order.