CVE-2026-31431 (Copy Fail) is a Linux kernel local privilege escalation vulnerability in the algif_aead module (AF_ALG). Any unprivileged local user can gain root via a 732-byte Python exploit. All kernels since 2017 are affected.
Details: copy.fail · Xint write-up · NVD · AlmaLinux announcement
An interim advisory with the temporary mitigation was published on 2026-04-30, ahead of the patched kernels and KernelCare livepatch. We did not wait for all patches to be ready before sharing protection guidance. This advisory is the full follow-up release.
| Version | Affected | Patched via |
|---|---|---|
| CL7 | No | — |
| CL7h, CL8 | Yes | CloudLinux kernel |
| CL9, CL10 | Yes | AlmaLinux kernel |
A KernelCare livepatch will also be available as an alternative on all affected versions — see Stream 3 below for current status.
There are three release streams. Use the one that applies to your CL version.
Target versions:
Both are CloudLinux rebuilds of the AlmaLinux 8 fix kernel-4.18.0-553.121.1.el8_10.
Note
While the patched kernel is only in the beta channel, you may prefer not to install it on production right away. In that case, apply the temporary mitigation below. It does not require a new kernel and can be reverted in seconds once the kernel reaches the stable channel.
Instructions for CL8
The patched kernel lands first in the CloudLinux beta channel (cloudlinux-updates-testing). Enable it for a single update:
yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
reboot
uname -rInstructions for CL7h
The patched kernel lands in the cl7h_beta repository. Enable it for a single update:
yum --enablerepo=cl7h_beta update 'kernel*'
reboot
uname -rA plain update will pull the patched version, no extra repo enablement needed:
yum update 'kernel*'
reboot
uname -rCL9 and CL10 use the AlmaLinux kernel directly. The patched kernel is currently available in the AlmaLinux testing repository; production repositories are expected to follow shortly. See the AlmaLinux announcement for upstream details.
Target versions:
The almalinux-release-testing package is not in CloudLinux repositories — install it from a direct URL, update the kernel, then disable the testing repo.
For CL10:
# 1. Enable the AlmaLinux 10 testing repo
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
# 2. Update the kernel
dnf update 'kernel*'
# 3. Reboot
reboot
# 4. Verify — expected kernel-6.12.0-124.52.2.el10_1 or later
uname -r
# 5. Disable the testing repo
dnf config-manager --disable almalinux-testingFor CL9 — same flow, replace the URL in step 1:
dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpmA plain update will pull the patched version, no testing-repo step needed:
dnf update 'kernel*'
reboot
uname -rUpdate: May 1, 5:12pm UTC
The K20260501_02 (oel8-uek6) KernelCare live patch for CVE-2026-31431 ("CopyFail") is released to the main feed. Customers on this main feed will receive the fix automatically on their next kcarectl --update
Additionally, patches for the following operating systems are published on the test feed:
In order to deploy from the test feed, run the following command:
kcarectl --update --prefix testThen confirm with:
kcarectl --patch-info --prefix test | grep CVE-2026-31431Once you have deployed the patch from the test feed, please provide us feedback (both positive or negative) by opening a support ticket.
Update: May 1, 2:50pm UTC
The K20260501_10 (rocky9) KernelCare live patch for CVE-2026-31431 ("CopyFail") is released to the main feed. Customers on this main feed will receive the fix automatically on their next kcarectl --update
Additionally, K20260501_13 (CL8) is now published on the test feed. In order to deploy from the test feed, run the following command:
kcarectl --update --prefix testThen confirm with:
kcarectl --patch-info --prefix test | grep CVE-2026-31431Once you have deployed the patch from the test feed, please provide us feedback (both positive or negative) by opening a support ticket.
Update: May 1, 12:48pm UTC
The following KernelCare live patches for CVE-2026-31431 ("CopyFail") are released to the test feed:
Update: May 1, 7:34am UTC
The first KernelCare live patches for CVE-2026-31431 ("CopyFail") are now published on the main feed:
Customers on this main feed will receive the fix automatically on their next kcarectl --update
Update: May 1, 12am CET.
AlmaLinux 9.6 ESU/FIPS fix (almalinux9 kernel-5.14.0-570.62.1.el9_6.tuxcare.1 through .els3) is available in test feed as K20260430_07
Update: April 30, 6pm CET.
KernelCare engineering has identified the fix set (3 upstream commits, not just the algif_aead revert), validated it against the published exploit on AlmaLinux 9.6-FIPS and UEK7, and is rolling it out across all supported distros ahead of vendor erratas. First release (alma9.6-esu/FIPS) is in review today — others are in active build/test. No customer action required — the live patch will be delivered automatically.
The KernelCare livepatch for this CVE is being prepared. Once published, KernelCare-subscribed systems will receive the fix automatically through the usual livepatch flow:
kcarectl --update
kcarectl --info | grep CVE-2026-31431The CVE should appear as patched in the kcarectl --info output.
Not using KernelCare yet? You can get started in just a few minutes. Find more information here.
After update + reboot:
uname -rCompare to the target version for your CL stream above.
For KernelCare:
kcarectl --info | grep CVE-2026-31431If applying a kernel update or KernelCare livepatch right now is not possible, you can blacklist the algif_aead initcall via grubby to prevent the AEAD AF_ALG interface from being registered at boot. This closes the attack surface without replacing the kernel. Requires a reboot.
Apply the restriction via grubby and reboot:
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo rebootAfter reboot, confirm the parameter is on the active kernel command line — it should contain initcall_blacklist=algif_aead_init:
sudo grubby --info=ALL | grep initcall_blacklistTo revert after a patched kernel is installed:
sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo rebootCompatibility: dm-crypt / LUKS, kTLS, IPsec, SSH, and default OpenSSL / GnuTLS builds do not depend on AF_ALG and are unaffected. Only applications that explicitly use AF_ALG for AEAD ciphers (rare on web hosting — e.g., OpenSSL with the afalg engine enabled, or hardware crypto offload via AF_ALG) will be impacted.
Additional protection for Imunify360 users
Imunify360 already detects the published indicators of compromise for CVE-2026-31431 and uses extended heuristics to identify and mitigate new indicators more quickly. This is an additional layer of defense — it does not replace the kernel update, but customers running Imunify360 are covered against currently observed exploitation attempts in the meantime.
Warning: The recommended mitigation from the original sources does not work
The modprobe-based workaround circulating on oss-security — adding the line install algif_aead /bin/false to a file under /etc/modprobe.d/ and running rmmod algif_aead — does not work on CloudLinux, AlmaLinux, or any other RHEL-family distribution.
The algif_aead module is built into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), so modprobe.d rules cannot block its loading and rmmod cannot remove it. The commands run without errors but leave the system unchanged — applying them gives a false sense of protection.
You can confirm the module is built-in on any system:
modinfo algif_aead | grep filename
# (builtin)