Copy Fail (CVE-2026-31431): What Linux infrastructure teams need to do now

A 732-byte Python script can get root on every major Linux distro shipped since 2017. Here is what you need to know and how to fix it today.

TL;DR

• CVE-2026-31431 "Copy Fail" is a local privilege escalation in the Linux kernel. CVSS 7.8. A trivial exploit gives any unprivileged user root access. No race condition, no crash, 100% reliable.
• Every major distro since 2017 is affected: Ubuntu, RHEL, Debian, Amazon Linux, SUSE, Rocky, Alma, Oracle Linux, Arch, and Fedora.
• Act now: patch your kernel or disable the vulnerable module in two commands.

What is Copy Fail?

The vulnerability lives in the kernel's cryptographic subsystem, specifically in how the authencesn template handles memory when processing data through AF_ALG sockets.

In 2017, a performance optimization changed algif_aead.c to reuse memory pages in place rather than copying them. That optimization introduced a subtle logic bug: when a user splices a file's cached pages into an AF_ALG socket for decryption, the kernel writes 4 attacker-controlled bytes past the expected output boundary, directly into the page cache.

The page cache is the kernel's in-memory copy of files on disk. Corrupting it means an attacker can modify what the kernel thinks a file contains without ever touching the disk. Standard file-integrity tools like AIDE, Tripwire, rpm -V, and debsums see nothing. The corruption does not survive a reboot, but the attacker does not need it to. They inject shellcode into a setuid binary like /usr/bin/su, execute it, and have root.

The exploit is 732 bytes of Python. It uses only standard library modules, works on every tested architecture and distro, and requires no race condition or retry logic. It just works.

Am I affected?

If you are running a Linux kernel compiled after the 2017 optimization (commit 72548b093ee3) and before the fix (commit a664bf3d603d), you are vulnerable. In practice, that means nearly every production Linux system.

Confirmed vulnerable:

• Ubuntu 20.04, 22.04, 24.04 (all variants including AWS, Azure, GCP, HWE, FIPS)
• Amazon Linux 2 and 2023
• RHEL (classified as "Important" severity)
• Debian Bullseye, Bookworm, and Trixie (no fix yet for stable releases)
• SUSE 16
• Rocky, Alma, Oracle Linux, Arch, Fedora

Not affected:

• Ubuntu 26.04 (Resolute)
• Workloads running on AWS Lambda/Fargate (Firecracker microVMs), gVisor, or Cloudflare Workers (V8 isolates), which provide kernel-level isolation per tenant

Containers do not protect you. The page cache is a host-kernel resource shared across all containers. Exploitation inside one container compromises the host and every co-tenant. This applies to Kubernetes clusters, CI/CD runners, and any container-based sandbox sharing a kernel.

Mitigation

Option A: Patch your kernel

The mainline fix is commit a664bf3d603d, merged April 1, 2026. Check your distro's security tracker for the patched kernel version:

• Ubuntu: Patches available for supported releases
• Debian: Fixed in Forky (6.19.13-1) and Sid (6.19.14-1). Stable releases still pending.
• Amazon Linux: Pending fix across AL2 and AL2023 variants
• RHEL: Advisory expected shortly
• SUSE: Check suse.com/security/cve/CVE-2026-31431

After updating your kernel package, reboot to load the patched kernel.

Option B: Workaround (if you cannot patch yet)

Disable the vulnerable kernel module in two commands:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null || true

This prevents the module from loading. It does not break dm-crypt/LUKS, kTLS, IPsec, SSH, or OpenSSL in its default configuration. The only edge case: applications that explicitly enable the OpenSSL afalg engine or bind AEAD sockets directly via AF_ALG. That configuration is rare.

Apply this workaround across every host, including container hosts and Kubernetes nodes.

Detection

This exploit is designed to be invisible to standard tools. The page cache corruption never writes back to disk, so file checksums look clean.

To detect exploitation attempts:

• Monitor AF_ALG socket creation. Legitimate AF_ALG usage is rare on most systems. Audit rules or seccomp policies on socket(AF_ALG) will flag unusual activity.
• Watch for anomalous setuid behavior. Look for setuid binaries (especially /usr/bin/su) spawning unexpected child processes.
• Check kernel logs. Unexpected entries referencing algif_aead or the crypto subsystem may indicate probing.

If you suspect compromise, rebooting clears the page cache corruption. Then patch or apply the workaround before bringing the system back into service.

For American Cloud customers

If you are on an American Cloud managed hosting plan, our team is already rolling out kernel patches across affected systems. No action is required on your part, and we will notify you when patching is complete.

If you manage your own kernels on American Cloud bare metal or VMs, apply the workaround above immediately and schedule a kernel update. Login and open a ticket with support or email [email protected] if you need help assessing your exposure.

This is a serious vulnerability with a trivial exploit. Treat it as a priority.