Kernel Vulnerability 'Copy Fail' (CVE-2026-31431)

linux security

CVE-2026-31431 is a local privilege escalation in the Linux kernel crypto API. Red Hat rates it Important (CVSS 7.8). Affected are RHEL 8, 9 and 10 (kernel and kernel-rt) and OpenShift Container Platform 4. Until the kernel patch is in, the official boot-parameter mitigation should be on every RHEL host.

Update 2026-05-13: Red Hat moved bulletin RHSB-2026-002 "Copy Fail" to "Resolved", all fixes are available. The CVE has been on the CISA KEV catalog since 2026-05-01, active exploitation is confirmed.

Update 2026-05-06: Patches are rolling out. Red Hat published its official RHSAs around 2026-05-04 / 2026-05-05. Rocky Linux 8, 9 and 10 follows within 24 to 48 hours via the standard BaseOS mirrors, according to the Rocky Linux forum (post 65, 2026-05-06 06:42 UTC). Quick check before updating:

$ sudo dnf check-update kernel
$ sudo dnf upgrade kernel
$ sudo systemctl reboot

If you are still relying on the boot-parameter mitigation, reboot after the update lands and roll the mitigation back (see Apply the patch).

What it is

An incorrect in-place operation was introduced in the algif_aead module: source and destination data mappings differ. Through AF_ALG sockets a local unprivileged userspace process can exploit this and gain root. We reproduced the bug on Rocky Linux 9 and 10; in container setups it additionally allows escaping to the host.

Key facts:

  • Red Hat public date: 2026-04-22, severity Important, CVSS v3 vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • Researcher disclosure: 2026-03-29 (Xint Code, copy.fail)
  • Affected per Red Hat: RHEL 8, 9, 10 and OpenShift Container Platform 4
  • Not affected: RHEL 6, 7 ("Vulnerable Code not Present")

Am I affected?

A kernel config check covers every distro:

$ grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
# =y     => built into the kernel (RHEL and compatibles)
# =m     => loadable module (Debian, Ubuntu, many others)
# empty  => not compiled in, not affected

For =m, also check whether the module is currently loaded:

$ lsmod | grep algif_aead

For =y lsmod is not an indicator, since the module is permanent kernel code. If you actively use AF_ALG sockets (rare, mostly custom crypto stacks):

$ sudo lsof 2>/dev/null | grep AF_ALG
$ ss -xa | grep -i alg

Mitigation on RHEL and compatible distros

On RHEL, Rocky Linux, AlmaLinux, CentOS Stream and Oracle Linux algif_aead is built into the kernel. Modprobe blacklists do not work. Red Hat instead blocks the initcall of the affected function at boot:

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

Pick one of the three variants, do not combine them:

  • initcall_blacklist=algif_aead_init: block only the AEAD path (Red Hat's recommendation)
  • initcall_blacklist=af_alg_init: disable the entire AF_ALG interface
  • initcall_blacklist=crypto_authenc_esn_module_init: block only the specific affected algorithm

Red Hat notes a possible performance impact for applications that use the kernel crypto API. Original wording in the Red Hat statement on CVE-2026-31431.

Verify after reboot:

$ cat /proc/cmdline | grep initcall_blacklist
$ dmesg | grep -i initcall

Rollback once the kernel patch is in:

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

Mitigation on distros with a loadable module

For hosts with =m (e.g. Debian, Ubuntu) a modprobe block is sufficient until the kernel patch is available:

$ echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
$ sudo rmmod algif_aead 2>/dev/null || true

Validation:

$ lsmod | grep algif_aead              # empty
$ sudo modprobe -v algif_aead          # "install /bin/false" and an error

Blocking the module is harmless on typical systems: dm-crypt/LUKS, kTLS, IPsec, OpenSSL/GnuTLS/NSS in standard builds, SSH and the kernel keyring crypto do not use AF_ALG. Custom crypto stacks (e.g. OpenSSL with the afalg engine) should be checked first.

Container hosts

The bug allows a container escape to the host. Kernel modules belong to the host and containers share the kernel, so the mitigation must go on the host. A container-only seccomp, SELinux or AppArmor policy is not enough.

Apply the patch

Once your distribution ships the fix:

# RHEL and compatibles
$ sudo dnf check-update kernel

# Debian / Ubuntu
$ sudo apt update && apt list --upgradable | grep linux-image

Apply the update, reboot, then remove the mitigation (rollback block above for RHEL, or sudo rm /etc/modprobe.d/disable-algif.conf plus reboot for loadable modules).

Patches are available (see the update notice at the top). Keep an eye on the Red Hat CVE entry and our own mirror servers for follow-up errata.

We can help

Need help patching or hardening your Linux servers? Have a look at our Service & Support plans and get in touch.

Previous Post Next Post

DE · EN