[New] CVE-2026-31431: Copy Fail Mitigation

ci/vale/dictionary.txt

@@ -211,6 +211,7 @@ bitwise
 Bjarne
 blkid
 blockchain
+blocklisted
 blocklists
 Blockly
 blockwise
@@ -2321,6 +2322,7 @@ seafile
 seahub
 searchbots
 searchterm
+seccomp
 secondsite
 secretpassword
 sed

docs/guides/security/security-patches/cve-2026-31431-copy-fail-mitigation/index.md

@@ -0,0 +1,87 @@
+---
+slug: cve-2026-31431-copy-fail-mitigation
+title: "CVE-2026-31431: Copy Fail Mitigation"
+description: 'CVE-2026-31431 ("Copy Fail") is a Linux vulnerability publicly disclosed on April 29, 2026. This article shows how to identify vulnerable systems and apply mitigation.'
+authors: ["Akamai"]
+contributors: ["Akamai"]
+published: 2026-05-05
+keywords: ['copy fail','CVE-2026-31431']
+license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)'
+external_resources:
+- '[NVD - CVE-2026-31431](https://nvd.nist.gov/vuln/detail/CVE-2026-31431)'
+- '[Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. - Xint](https://xint.io/blog/copy-fail-linux-distributions)'
+---
+
+[CVE-2026-31431](https://nvd.nist.gov/vuln/detail/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](https://xint.io/blog/copy-fail-linux-distributions) 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:
+
+```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
+
+```command
+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:
+
+```command
+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](https://wiki.ubuntu.com/Kernel/KernelBootParameters) 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](https://github.com/moby/profiles/blob/main/seccomp/default.json#L449) does already block `AF_ALG` sockets (albeit indirectly, by allowing all others except `AF_ALG`).
+
+## Akamai Cloud (Linode)
+
+Per our [Shared Security Model](https://www.akamai.com/legal/security), 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](https://techdocs.akamai.com/cloud-computing/docs/manage-the-kernel-on-a-compute-instance), 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.