CVE-2026-31431: Copy Fail Mitigation

CVE-2026-31431 (termed “Copy Fail”) is a Linux kernel local privilege escalation in the algif_aead module (AF_ALG) that was publicly disclosed on April 29, 2026. The publication of the vulnerability included a trivial, 732-byte Python exploit as proof of concept, which demonstrates that any unprivileged user can elevate their access to full superuser privileges. All common Linux distributions since 2017 are affected.

Copy Fail abuses a logic flaw in the Linux kernel’s algif_aead crypto module, introduced through a 2017 optimization. By manipulating the kernel’s AF_ALG crypto interface, an attacker can write controlled data into the Linux page cache.

This allows a local attacker to, for example, hijack setuid binaries like /usr/bin/su, change their user’s UID, or execute any number of other privilege escalation vectors. As such, this vulnerability has the highest and most immediate impact for systems that allow for untrusted users to execute code such as in, e.g., a multi-user environment as well as for those utilizing containers with untrusted workloads.

While it is important to stress that this vulnerability cannot be exploited remotely by itself, patching or mitigating the exploit path is nevertheless strongly recommended on all affected systems so as to ensure that no unauthorized or even unexpected remote access in, e.g., an automated environment could be elevated in combination with this local privilege escalation into a remote root vulnerability.

Mitigations

Patches to address the vulnerability have been released by upstream vendors of major Linux distributions. If your distribution has no upstream release available, you may be able to apply temporary mitigations as explained below.

To check whether algif_aead is compiled into the kernel or is made available as a loadable kernel module, you can run the following command:

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
CONFIG_CRYPTO_USER_API_AEAD=m

If the /boot/config file does not exist, you can also check the running config via

zgrep CONFIG_CRYPTO_USER_API_AEAD /proc/config.gz
CONFIG_CRYPTO_USER_API_AEAD=m

In this example, CONFIG_CRYPTO_USER_API_AEAD=m indicates that algif_aead is available as a loadable kernel module. In that case, you can prevent the module from being loaded by running these commands:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead

This removes the loaded module and prevents the AF_ALG AEAD interface from being used, effectively blocking the exploit path. For the vast majority of environments this has no noticeable impact, as only applications using AF_ALG may be affected.

If the zgrep command above returned a # CONFIG_CRYPTO_USER_API_AEAD is not set instead of CONFIG_CRYPTO_USER_API_AEAD=m, then the system does not support AF_ALG at all and is safe against this vulnerability. If instead it returned CONFIG_CRYPTO_USER_API_AEAD=y, then the system is vulnerable, since support is directly compiled into the kernel and the rmmod command above would thus fail. In this case, you may be able to set a kernel boot parameter of initcall_blacklist=algif_aead_init and then reboot to block the exploit path.

If you are using Docker, you may wish to ensure that your seccomp profile denies AF_ALG sockets; the default Docker seccomp policy does already block AF_ALG sockets (albeit indirectly, by allowing all others except AF_ALG).

Akamai Cloud (Linode)

Per our Shared Security Model, customers are responsible for making sure their service’s installed applications and code are securely configured and patched. Given the nature of this vulnerability, it should be assumed that all virtual machines running Linux are at-risk until patched.

As a local privilege escalation, this vulnerability is not exploitable remotely by itself. Therefore, it is most urgent to fix in multi-tenant / multi-user workloads, or workloads where you allow external code to be executed as a non-privileged user, including in a container environment. The specifics of your risk exposure will depend highly on your environment, workload, and applications.

Depending on which environment your applications are running in, you have a number of options.

For virtual machines (Linode VMs) you can:

• Upgrade the OS in your VM to vendor supplied patches following instructions from the OS vendor.

• Ensure the loadable kernel module is blocklisted and unloaded, as described above.

• Install new Linode VMs using our updated base images containing the upstream fixes. At this time we have received upgraded/patched images from upstream providers for:

  • AlmaLinux 10, 9, and 8
  • Alpine Linux 3.23, 3.22, and 3.21
  • ArchLinux
  • CentOS Stream 9
  • Debian 13, 12, and 11
  • Fedora 43 and 42
  • OpenSUSE Leap 15.6
  • Rocky Linux 9 and 8
  • Slackware 15.0
  • Ubuntu 25.10, 24.04 LTS, 22.04 LTS, and 20.04 (API only)

  We will continue to update the OS versions as upstream providers issue new releases.

• Older versions of the different Linux distributions remain available for customers to launch. The reason for this is that we cannot assess for our customers what risks they are willing to accept, and that we cannot break automated deployment pipelines for them. We strongly recommend that customers who continue to deploy older releases manually mitigate the vulnerability as described above.

• If you are using “GRUB 2” (default since August 2018), your Linode will boot with the kernel in the OS disk image. However, if you are still using one of our kernels to boot, the latest kernel configuration (version 7.0.3) contains the patch for the vulnerability. Older Linode provided kernel configurations (e.g., “6.15.7-x86_64-linode169”) remain vulnerable. Customers using these configurations are strongly encouraged to switch to the latest kernel and reboot, or use “GRUB 2” to boot from their own kernel on their primary disk, which has been Linode’s default boot option since 2018.

For Linode Kubernetes Engine (LKE and LKE-E), the underlying nodes run a Linux kernel based on the Debian 12 (for LKE) and Ubuntu 22/24 (for LKE-Enterprise) distribution. Existing deployments will need patching until we can provide updated images. We will update this post when they are available. You can choose one of the following options:

• The most durable option is to apply the mitigations outlined above via a DaemonSet. This will ensure mitigations are in place should scaling provision new nodes.
  • Note: A RuntimeDefault seccomp profile is insufficient.
• Alternatively, mitigations can be applied manually or via infrastructure as code (IaC) tools like Terraform or Ansible.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

• NVD - CVE-2026-31431
• Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. - Xint