Mitigating CVE-2026-31431 on Rocky Linux 8, 9, 10, and LTS Variants
Introduction
CVE-2026-31431 ("copy.fail") is a local privilege escalation vulnerability in the Linux kernel's AF_ALG AEAD socket interface (crypto/algif_aead.c). A reliable public exploit exists with reimplementations in Python, C, Go, and arm64. This article documents a verified mitigation that disables the vulnerable code path until a patched kernel is available.
This applies broadly across the Rocky Linux 8, 9, and 10 product family, including the CIQ LTS variants:
- Rocky Linux 8 (all minor versions, e.g. kernel
4.18.0-553.109.1.el8_10and earlier) - Rocky Linux 8 LTS / EUS (e.g. kernel
4.18.0-553.117.1+2.1.el8_6_ciqon 8.6 LTS; includes pinned variants such as 8.8) - Rocky Linux 9 (all minor versions)
- Rocky Linux 9 LTS / EUS (pinned variants such as 9.2 and 9.4)
- Rocky Linux 10 (all minor versions)
Confirm by checking the running kernel's config:
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
If the output is CONFIG_CRYPTO_USER_API_AEAD=y, the vulnerable algorithm family is built directly into the kernel image, not compiled as a loadable module. This is the default on the Rocky 8, 9, and 10 kernels above.
Problem
Any local unprivileged user can open an AF_ALG socket of type aead, bind to an algorithm such as authencesn(hmac(sha256),cbc(aes)), and trigger the vulnerability to gain root. Because the AEAD interface is registered automatically at boot via the kernel's initcall mechanism, the attack surface is present on every affected system without any special configuration.
Status
- Patched kernel: in development. CIQ Engineering is backporting the fix for the affected Rocky Linux 8, 9, 10, and LTS / EUS variants. We will publish patched kernels into the relevant CIQ update repositories as soon as they are ready.
- Recommended action now: apply the mitigation documented below. It has been verified to block the public exploit and is reversible once a patched kernel is installed.
- Resolution: update to the patched kernel as soon as it appears in your update repository. For LTS / EUS customers this is the relevant CIQ repository; for standard Rocky Linux installations it is the upstream Rocky update channel. This article will be updated with the fixed kernel version when each is available.
- Open a support case if you need help confirming exposure on your fleet, validating the mitigation against your workload, or tracking the patched kernel release for your specific Rocky Linux variant.
Mitigation
On all affected EL kernels, crypto/algif_aead.c is compiled directly into the kernel image (CONFIG_CRYPTO_USER_API_AEAD=y), not as a loadable module (=m). That has two practical consequences for anyone trying to mitigate this without a kernel update:
- There is no
algif_aead.koforrmmodto unload, so the standard "remove the module" approach does not apply. - An
/etc/modprobe.d/blacklist has nothing to match against, since the code is part of the kernel image rather than a module the kernel would otherwise load.
The supported way to disable a built-in initcall is the kernel command-line parameter initcall_blacklist, which tells the kernel to skip a named initcall function during boot. Adding initcall_blacklist=algif_aead_init prevents the AEAD algorithm family from registering, so user-space attempts to bind to AEAD algorithms via AF_ALG fail with ENOENT. The same parameter also works on kernels where the code is built as a module, so it is the cleanest single recipe across all the affected variants.
⚠️ WARNING Disabling AEAD registration removes a kernel feature that some software relies on. Read the Notes section below and validate against your workload before rolling this out fleet-wide. This is a mitigation, not a fix. Revert it once a patched kernel is installed.
Apply the parameter and reboot:
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot
After the reboot, verify the parameter is on the active command line:
cat /proc/cmdline | grep initcall_blacklist
You should see initcall_blacklist=algif_aead_init in the output.
Then confirm the kernel actually skipped the AEAD initcall by checking the kernel ring buffer:
sudo dmesg | grep -i 'initcall.*algif_aead'
You should see a line indicating the initcall was blacklisted at boot. If you do not see it, the kernel command line was not honored. Re-check the cmdline output above and confirm the system was rebooted after grubby ran.
Reverting the mitigation
Once a patched kernel is installed and booted, remove the parameter:
sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot
Root Cause
The vulnerability is in crypto/algif_aead.c in the AF_ALG AEAD socket interface. The upstream fix is commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5. The vulnerable code path is reachable on any kernel where CONFIG_CRYPTO_USER_API_AEAD is enabled, which is the default on Rocky Linux 8, 9, and 10, and the corresponding LTS / EUS kernels.
Notes
The mitigation has scope beyond just the exploit. Before applying it widely, evaluate the impact on the following:
- IPsec ESN (Extended Sequence Numbers). The AEAD subsystem is used by IPsec for ESN support. With AEAD disabled, IPsec connections that negotiated ESN fall back to standard sequence numbers, which means more frequent rekeying. Functionally still works, but rekeying cadence changes.
- Userspace consumers of AF_ALG AEAD.
cryptsetup,bluez,iwd, andlibkcapimay open AF_ALG AEAD sockets. Independent testing reported on the oss-security mailing list found inconclusive results withcryptsetup(no confirmed breakage, but the researcher noted further testing is warranted). If your workload depends on any of these for AEAD operations, test the mitigation in a non-production environment first. - OpenSSL afalg engine. OpenSSL builds with the afalg engine enabled continue to function for non-AEAD operations. The mitigation only blocks the AEAD algorithm family. The symmetric cipher (
algif_skcipher) and hash (algif_hash) interfaces remain active. - Public exploit availability. The original public exploit is a Python script that requires Python 3.11. On systems where only an older Python is available the script will not run unmodified, but C, Go, and arm64 reimplementations exist and run with no additional dependencies. The Python version constraint is not a meaningful security boundary. Treat any system with
CONFIG_CRYPTO_USER_API_AEAD=yas exploitable until patched or mitigated.
References & related articles
- Public exploit reference: github.com/theori-io/copy-fail-CVE-2026-31431
- Vulnerability landing page: copy.fail