--- title: "Kernel Vulnerability 'Copy Fail' (CVE-2026-31431)" url: 'https://www.linuxfabrik.ch/en/blog/kernel-vulnerability-copy-fail' markdown: 'https://www.linuxfabrik.ch/en/blog/kernel-vulnerability-copy-fail.md' lang: en date: '2026-04-30' description: 'Linux kernel vulnerability Copy Fail (CVE-2026-31431) affects RHEL and derivatives: privilege escalation. How to patch and how to check if you are exposed.' taxonomy: category: - blog tag: - linux - security archives_month: - apr_2026 archives_year: - '2026' --- [ Home ](https://www.linuxfabrik.ch/en) [ Blog ](https://www.linuxfabrik.ch/en/blog) Kernel Vulnerability 'Copy Fail' (CVE-2026-31431) [CVE-2026-31431](https://access.redhat.com/security/cve/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"](https://access.redhat.com/security/vulnerabilities/RHSB-2026-002) to "Resolved", all fixes are available. The CVE has been on the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-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](https://forums.rockylinux.org/t/cve-2026-31431-copy-fail-linux-kernel-crypto-vulnerability/20375) (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](#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](https://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](https://access.redhat.com/security/cve/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](https://access.redhat.com/security/cve/CVE-2026-31431) and our own [mirror servers](https://www.linuxfabrik.ch/en/services/mirror-server) for follow-up errata. ## We can help Need help patching or hardening your Linux servers? Have a look at our [Service & Support plans](https://www.linuxfabrik.ch/en/services/service-support) and [get in touch](https://www.linuxfabrik.ch/en/contact). [ Previous Post](https://www.linuxfabrik.ch/en/blog/linuxfabrik-firewallfabrik-release-v1.0.0) [Next Post ](https://www.linuxfabrik.ch/en/blog/kernel-vulnerability-dirty-frag) #### Tags [ansible](https://www.linuxfabrik.ch/en/blog/tag:ansible) [checklistfabrik](https://www.linuxfabrik.ch/en/blog/tag:checklistfabrik) [cloud](https://www.linuxfabrik.ch/en/blog/tag:cloud) [datacenter](https://www.linuxfabrik.ch/en/blog/tag:datacenter) [event](https://www.linuxfabrik.ch/en/blog/tag:event) [firewallfabrik](https://www.linuxfabrik.ch/en/blog/tag:firewallfabrik) [graylog](https://www.linuxfabrik.ch/en/blog/tag:graylog) [icinga](https://www.linuxfabrik.ch/en/blog/tag:icinga) [lfops](https://www.linuxfabrik.ch/en/blog/tag:lfops) [linux](https://www.linuxfabrik.ch/en/blog/tag:linux) [monitoring-plugins](https://www.linuxfabrik.ch/en/blog/tag:monitoring-plugins) [news](https://www.linuxfabrik.ch/en/blog/tag:news) [nextcloud](https://www.linuxfabrik.ch/en/blog/tag:nextcloud) [security](https://www.linuxfabrik.ch/en/blog/tag:security) #### Archives - [2026](https://www.linuxfabrik.ch/en/blog/archives_year:2026) - [2025](https://www.linuxfabrik.ch/en/blog/archives_year:2025) - [2024](https://www.linuxfabrik.ch/en/blog/archives_year:2024) - [2023](https://www.linuxfabrik.ch/en/blog/archives_year:2023) - [2022](https://www.linuxfabrik.ch/en/blog/archives_year:2022) - [2021](https://www.linuxfabrik.ch/en/blog/archives_year:2021) - [2020](https://www.linuxfabrik.ch/en/blog/archives_year:2020) #### Syndicate [ Atom](https://www.linuxfabrik.ch/en/blog.atom) [ RSS](https://www.linuxfabrik.ch/en/blog.rss) --- ## Navigation - Parent: [Blog](https://www.linuxfabrik.ch/en/blog.md) - Previous: [Kernel Vulnerability 'Dirty Frag' (CVE-2026-43284)](https://www.linuxfabrik.ch/en/blog/kernel-vulnerability-dirty-frag.md) - Next: [FirewallFabrik: the successor to Firewall Builder](https://www.linuxfabrik.ch/en/blog/linuxfabrik-firewallfabrik-release-v1.0.0.md)