Copy Fail (CVE-2026-31431) is a logic flaw in the Linux kernel's AF_ALG cryptographic socket interface that lets any unprivileged local user write four attacker-controlled bytes into the kernel's page cache — and use that to become root. A 732-byte Python script, unchanged, roots Ubuntu, Amazon Linux, RHEL, SUSE, and every other major distribution running a kernel from 2017 onward. It does not require a race condition. It works every time.

CISA added it to the Known Exploited Vulnerabilities catalog on May 1, 2026, and ordered US federal civilian agencies to patch by May 15. You have less excuse than they do — the fix ships in your distro's next kernel update.

What exactly is the bug?

The vulnerability lives in algif_aead, the AEAD socket interface inside the kernel's userspace crypto API (AF_ALG). A 2017 performance optimization to the authencesn cryptographic template introduced a logic error in how scatter-gather lists are handled during in-place operations. The result: an unprivileged process can trigger a controlled, deterministic 4-byte write into the page cache of any readable file on the system.

The page cache is the kernel's in-memory representation of files. If you corrupt the cached copy of a privileged binary — say, su or sudo — the kernel executes your modified version the next time it is called. The file on disk is never touched, so integrity checks that hash the disk image see nothing wrong. You have root. The host is yours.

Unlike Dirty Cow (2016) or Dirty Pipe (2022), Copy Fail involves no race condition and no kernel version gambling. The commit that introduced it is a664bf3d603d; the upstream fix is in place for all active kernel series.

Who is affected?

Every Linux system running kernel 4.14 or later where the algif_aead module is loaded — which is essentially every modern Linux installation, because the module loads on demand and is not disabled by default. Confirmed vulnerable distributions include:

  • Ubuntu 20.04, 22.04, 24.04 LTS
  • Amazon Linux 2, 2023
  • Red Hat Enterprise Linux 8, 9, 10.1
  • SUSE Linux Enterprise 15, 16
  • Debian stable and testing
  • Fedora, Arch Linux, AlmaLinux

The flaw also crosses container boundaries. If an unprivileged container shares a base image layer with a privileged container on the same Kubernetes node, an attacker inside the unprivileged container can corrupt a binary in the shared layer and trigger execution in the privileged context — a full container-to-node escape. This has been validated on Amazon EKS, Google GKE, and Alibaba Cloud ACK.

Check your exposure right now

Is the module currently loaded?

lsmod | grep algif_aead

If the command returns output, the module is active and the system is exploitable. If it returns nothing, the module is not loaded — but it may still be present and loadable on demand.

Is the module available on disk?

modinfo algif_aead 2>/dev/null && echo "Module present" || echo "Not found"

What kernel version are you running?

uname -r

Compare against the patched versions below.

Patched kernel versions

Kernel seriesFirst safe version
5.10.x5.10.254
5.15.x5.15.204
6.1.x6.1.170
6.6.x6.6.137
6.12.x6.12.85
6.18.x6.18.22
6.19.x6.19.12
7.0+All versions

If your distro has backported the fix, the package version will indicate it even if the kernel version number seems lower than the table above. Check your distribution's security advisory for the exact package version.

Mitigate immediately if you cannot patch

Disabling algif_aead eliminates the attack surface with no impact on the vast majority of workloads. Almost nothing in production depends on this interface.

For dynamically loaded modules (most systems):

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

The first command makes the module impossible to load after reboot. The second unloads it from the running kernel immediately. The || true prevents a non-fatal error if the module is not currently loaded.

If the module is compiled into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y):

Add the following to your kernel boot parameters in GRUB:

initcall_blacklist=algif_aead_init

Then update GRUB and reboot:

sudo update-grub   # Debian/Ubuntu
# or
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/Fedora

Apply the patch

On Debian/Ubuntu:

sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r)
sudo reboot

On RHEL/CentOS/AlmaLinux:

sudo dnf update kernel
sudo reboot

On Amazon Linux:

sudo yum update kernel
sudo reboot

After reboot, verify with uname -r that you are running a patched version.

If your workload cannot tolerate a reboot, live kernel patching is available. CloudLinux's KernelCare and SUSE's Live Kernel Patching both ship patches for CVE-2026-31431. [INTERN LÄNK: live kernel patching linux]

What about Kubernetes?

Patch the node kernel, not the container image. The vulnerability lives in the host kernel; containers share it. No container-level fix closes the hole.

For managed clusters (EKS, GKE, GKE Autopilot, AKS), your cloud provider is rolling out node OS updates. Check your cluster's node pool upgrade status in the console or CLI and trigger a rolling node replacement if auto-upgrade has not yet kicked in:

# EKS — update node group to latest AMI
aws eks update-nodegroup-version --cluster-name <cluster> --nodegroup-name <ng>
 
# GKE — trigger rolling node upgrade
gcloud container clusters upgrade <cluster> --node-pool <pool> --region <region>

As an interim measure, you can add the algif_aead blacklist via a DaemonSet that writes the modprobe configuration to each node's host filesystem — the deckhouse mitigation repository on GitHub has a ready-made manifest.

[INTERN LÄNK: Kubernetes node security hardening]

The exploit ecosystem

Multiple public implementations now exist beyond Theori's original 732-byte Python proof-of-concept: C and Go ports are on GitHub, and at least one Rust implementation has been spotted. Percivalll's Kubernetes-specific PoC demonstrates the container escape path and has been validated across three major cloud providers. Treat this vulnerability as weaponized and available to any attacker with local access to your systems.

CVSS score: 7.8 (High). The score reflects that exploitation is local-only — you cannot hit this remotely without a separate initial access vector. In practice, initial access is rarely the hard part.

The short version

  1. Run lsmod | grep algif_aead — if it shows output, act now.
  2. Disable the module via /etc/modprobe.d/disable-algif-aead.conf as a temporary mitigation.
  3. Patch the kernel as soon as your distribution ships the update, then reboot.
  4. Kubernetes: patch nodes, not containers; use your cloud provider's node-upgrade tooling.
  5. Verify the patched kernel is running with uname -r.

The federal deadline was May 15. This is not a vulnerability you monitor and patch during the next maintenance window — it is one you patch this week.

Sources