Contact us
Articles › Rocky Linux

Mitigating CVE-2026-31431 on Rocky Linux 8, 9, 10, and LTS Variants

cvesecuritykernelrocky linuxltsmitigationtroubleshooting

Arsalan Zaidi
Customer Support Engineering Team Lead

May 01, 2026

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. CIQ has shipped patched kernels for several RLC Pro LTS variants; this article documents both the resolution (install the patched kernel) and a verified boot-parameter mitigation for systems that cannot be updated immediately.

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_10 and earlier)
  • RLC Pro LTS 8.x (e.g. kernel 4.18.0-553.117.1+2.1.el8_6_ciq on 8.6 LTS; includes pinned variants such as 8.8)
  • Rocky Linux 9 (all minor versions)
  • RLC Pro LTS 9.x (pinned variants 9.2, 9.4, and 9.6)
  • 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 kernels are available for RLC Pro LTS 9.x variants 9.2, 9.4, and 9.6 as of 2026-05-01. See the Patched Kernels table below for exact versions.
  • Recommended action: install the patched kernel via dnf update kernel* and reboot. See the Installing the Update section for the full procedure, including any required repo or channel setup; after reboot, see the Resolution section for verification steps and how to revert the boot-parameter mitigation if you applied it.
  • If you cannot update yet: the Mitigation section documents a verified boot-parameter workaround that blocks the public exploit until a patched kernel is in place.
  • Open a support case if you need help confirming exposure on your fleet, validating the patched kernel against your workload, or tracking patch availability for a Rocky Linux variant not yet listed below.

Patched Kernels

Variant Patched Kernel Version Released
RLC Pro LTS 9.2 kernel-5.14.0-284.30.1+27.1.el9_2_ciq 2026-05-01
RLC Pro LTS 9.4 kernel-5.14.0-427.42.1+19.1.el9_4_ciq 2026-05-01
RLC Pro LTS 9.6 kernel-5.14.0-570.60.1+8.1.el9_6_ciq 2026-05-01
RLC Pro FIPS 9.2 kernel-5.14.0-284.30.1+27.1.el9_2_ciq 2026-05-01
RLC Pro FIPS 9.6 kernel-5.14.0-570.60.1+8.1.el9_6_ciq 2026-05-01
RLC Pro LTS 8.6 kernel-4.18.0-372.32.1+24.1.el8_6_ciq 2026-05-02
RLC Pro FIPS 8.10 kernel-4.18.0-553.120.1+3.2.el8_10_ciq 2026-05-03
RLC Pro FIPS 8.6 kernel-4.18.0-553.117.1+2.1.el8_6_ciq 2026-05-04
RLC Pro Hardened LTS 9.6 kernel-5.14.0-570.60.1+8.1.el9_6_ciq 2026-05-04
RLC Pro LTS 8.10 kernel-4.18.0-553.120.1+3.2.el8_10_ciq 2026-05-05
RLC Pro 8 kernel-4.18.0-553.120.1+3.2.el8_10_ciq 2026-05-05
RLC Pro 9 kernel-5.14.0-611.34.1+2.1.el9_7_ciq 2026-05-05
Rocky Linux 8.10 (Community) kernel-4.18.0-553.123.1.el8_10 2026-05-06
Rocky Linux 9.7 (Community) kernel-5.14.0-611.54.1.el9_7 2026-05-06
Rocky Linux 10.1 (Community) kernel-6.12.0-124.52.1.el10_1 2026-05-06

Confirm what is running on a given system with:

uname -r

If your system reports one of the patched versions above (or newer), the fix is in place and the boot-parameter mitigation can be reverted. See Resolution.

Installing the Update

RLC Pro LTS and FIPS Variants

For RLC Pro LTS and FIPS variants other than RLC Pro FIPS 8.10, the patched kernel is available directly from the long-term support repository. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

RLC Pro 8, RLC Pro 9, and RLC Pro LTS 8.10

For RLC Pro 8, RLC Pro 9, and the RLC Pro LTS 8.10 variant, the patched kernel is available in the Core Repo. To access it, refresh your DNF metadata and then enable the appropriate depot channel for your variant if you do not have the core repository:

sudo dnf refresh

Then enable the channel that matches your product:

sudo depot enable lts-8.10   # RLC Pro LTS 8.10
sudo depot enable rlc-pro-8  # RLC Pro 8
sudo depot enable rlc-pro-9  # RLC Pro 9

Once the channel is enabled or reenabled, install the update:

sudo dnf update kernel*
sudo reboot

Community Edition (RESF)

For Rocky Linux 8.10, 9.7, and 10.1 community editions from RESF, the patched kernel is available from the standard BaseOS repository. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

Resolution

After the reboot, verify that the running kernel matches the patched version listed in the Patched Kernels table:

uname -r

If you previously applied the boot-parameter mitigation (initcall_blacklist=algif_aead_init), remove it now that the fix is in place:

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

After that reboot, confirm the parameter is gone from the active command line:

grep initcall_blacklist /proc/cmdline

The grep should produce no output. The AEAD interface is then restored on the patched kernel, with the upstream fix in place rather than the workaround.

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.ko for rmmod to 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:

grep initcall_blacklist /proc/cmdline

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

Once a patched kernel ships for your variant, follow the Resolution section to install it and revert this mitigation.

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 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, and libkcapi may open AF_ALG AEAD sockets. Independent testing reported on the oss-security mailing list found inconclusive results with cryptsetup (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.10 or newer. 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=y as exploitable until patched or mitigated.

References & related articles