CVE-2026-31431 (Copy Fail): Kernel Update on CloudLinux

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.

Affected CloudLinux versions

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.

Update instructions

There are three release streams. Use the one that applies to your CL version.

Stream 1 — CloudLinux kernel (CL7h, CL8)

Target versions:

CL7h: kernel-4.18.0-553.121.1.lve.el7h.x86_64 or later
CL8: kernel-4.18.0-553.121.1.lve.el8.x86_64 or later

Both are CloudLinux rebuilds of the AlmaLinux 8 fix kernel-4.18.0-553.121.1.el8_10.

From the CloudLinux beta channel

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 -r

Instructions 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 -r

Once the kernel reaches the stable channel

A plain update will pull the patched version, no extra repo enablement needed:

yum update 'kernel*'
reboot
uname -r

Stream 2 — AlmaLinux kernel (CL9, CL10)

CL9 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:

CL9: kernel-5.14.0-611.49.2.el9_7 or later
CL10: kernel-6.12.0-124.52.2.el10_1 or later

From the AlmaLinux testing repository

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-testing

For 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.rpm

Once the kernel reaches AlmaLinux production repositories

A plain update will pull the patched version, no testing-repo step needed:

dnf update 'kernel*'
reboot
uname -r

Stream 3 — KernelCare livepatch (all affected versions)

Update: May 1, 7:34am UTC

The first KernelCare live patches for CVE-2026-31431 ("CopyFail") are now published on the main feed:

AlmaLinux 9.6 FIPS (ESU) (release K20260430_07)
AlmaLinux 9.2 FIPS (ESU) (release K20260430_13)

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-31431

The 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.

How to verify you are patched

After update + reboot:

uname -r

Compare to the target version for your CL stream above.

For KernelCare:

kcarectl --info | grep CVE-2026-31431

Temporary mitigation (if you cannot update immediately)

If 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 reboot

After 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_blacklist

To revert after a patched kernel is installed:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

Compatibility: 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)