How to Fix Copy Fail (CVE-2026-31431) on Ubuntu, Debian, Fedora, RHEL, AlmaLinux and Arch

How to Fix Copy Fail – Updated: May 5, 2026
Covers all major distributions with verified patch commands

If you read our original Copy Fail coverage and are now ready to actually fix it — this is the article you need. Patches are now available for most major distributions, and where they are not yet, there are working interim mitigations. This guide gives you the exact commands for your distro, nothing more.

One important correction from our earlier article: the modprobe blacklist workaround we included for blocking the algif_aead module does not work on RHEL-family distributions (RHEL, AlmaLinux, Rocky Linux, CentOS Stream, CloudLinux). On these systems the algif_aead module is built directly into the kernel, so modprobe.d rules cannot block its loading and rmmod cannot remove it. The commands run without errors but leave the system completely unchanged — applying them gives a false sense of protection. The correct mitigation for RHEL-family systems is covered below.

Copy Fail (CVE-2026-31431): The Worst Linux Security Vulnerability in Years

---

Step 1 — Check if you are vulnerable

Run this on any Linux system to see your current kernel version:

bash

uname -r

The mainline fix was committed on 1 April 2026. Fixed kernel versions are 6.18.22, 6.19.12, and 7.0. If your kernel is older than these and your distro has not yet pushed a patched package, follow the instructions for your distribution below.

Also check whether the vulnerable module is currently loaded:

bash

grep -qE '^algif_aead ' /proc/modules && echo "Vulnerable module IS loaded" || echo "Vulnerable module is NOT loaded"

---

Ubuntu

The vulnerability affects all Ubuntu releases before Resolute (26.04). Ubuntu 26.04 and later kernels are not affected.

The Ubuntu Security Team has released mitigations which disable the affected Linux kernel module in the kmod package. Linux kernel packages which implement the proposed patch are being released.

Apply the patch:

bash

sudo apt update && sudo apt upgrade
sudo reboot

If a kernel update is not yet available, apply the interim mitigation:

bash

# Check if the module is loaded
grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

# Unload the module (if loaded)
sudo rmmod algif_aead

# Prevent it loading on next boot
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo update-initramfs -u

If you have Ubuntu Pro with Livepatch enabled, the patches will be automatically applied within 24 hours of being available. Rebooting the system will ensure the mitigation is applied irrespective of the current state.

Verify the fix:

bash

uname -r  # Should show a patched kernel version
grep -qE '^algif_aead ' /proc/modules && echo "Still loaded — reboot required" || echo "Module not loaded — protected"

---

Debian

The modprobe blacklist approach works correctly on Debian because algif_aead is a loadable module, not built into the kernel.

Apply the patch (once available in your release channel):

bash

sudo apt update && sudo apt full-upgrade
sudo reboot

Interim mitigation:

bash

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

Check your distribution’s security tracker at security-tracker.debian.org for the latest patch status for your Debian release.

---

Fedora

Fedora’s rolling release cadence means patched kernels typically arrive faster than stable distributions. Check for updates immediately:

bash

sudo dnf update kernel
sudo reboot

Confirm you are running a patched kernel after reboot:

bash

uname -r

---

RHEL, AlmaLinux, Rocky Linux — Important: different mitigation required

This is where the guidance differs significantly from Debian-based systems and from the mitigation that has been widely circulated online.

The algif_aead module is built into the kernel on RHEL-family distributions. The modprobe-based workaround does not work here — the commands run without errors but leave the system unchanged.

The correct interim mitigation for all RHEL-family distributions is to blacklist the module via the kernel command line using grubby:

Interim mitigation (RHEL-family — use this, not modprobe):

bash

# Blacklist the algif_aead initcall via grubby
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

# Reboot to apply
sudo reboot

# After reboot, verify the parameter is active
sudo grep -o 'initcall_blacklist=[^ ]*' /proc/cmdline
# Should output: initcall_blacklist=algif_aead_init

Apply the patch (AlmaLinux — patched kernels are now in production):

Patched kernels are now rolling out to production repositories. Run the following:

bash

sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

Apply the patch (RHEL):

bash

sudo dnf update kernel
sudo reboot

Check access.redhat.com/security for the latest RHEL advisory status.

Remove the interim mitigation after patching:

bash

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

---

Arch Linux

Arch’s rolling release model means a patched kernel is likely already available in the main repository:

bash

sudo pacman -Syu
sudo reboot

Verify after reboot:

bash

uname -r

---

Amazon Linux

bash

sudo dnf update kernel
sudo reboot

Check aws.amazon.com/security/security-bulletins for the Amazon Linux advisory.

---

SUSE / openSUSE

bash

sudo zypper refresh && sudo zypper update kernel-default
sudo reboot

---

What is safe to use while the mitigation is active?

A common concern after disabling algif_aead is whether it breaks encryption, SSH, or other critical system functions. This workaround does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. Standard disk encryption, VPNs, and secure connections are all unaffected. The only things that may be affected are applications explicitly configured to use the afalg engine for hardware-accelerated cryptographic operations — which is uncommon outside of specialised setups.

You can check whether anything on your system is actively using AF_ALG before disabling it:

bash

sudo lsof | grep AF_ALG

If that returns nothing, disabling the module has no practical impact on your running system.

---

Container and Kubernetes environments

If you run containers or Kubernetes nodes, patching the host kernel is the only complete fix. The interim module mitigation applies at the host kernel level and protects all containers running on that host — but it must be applied to every node individually.

Until you have patched kernels deployed across your cluster, treat any container remote code execution as a potential host-level compromise. Enforce rapid node recycling after any indicators of compromise are detected, and audit your nodes for signs of exploitation:

bash

# Check for unexpected setuid binary modifications (in-memory only — check running processes)
sudo ausearch -k privilege_escalation 2>/dev/null | tail -20

# Check for unexpected root processes spawned by non-root users
ps aux | awk '$1 != "root" && $8 == "root"'

---

Patch status at a glance

Distribution	Patch available?	Method
Ubuntu 24.04 LTS	Yes	apt update && apt upgrade
Ubuntu 26.04	Not affected	N/A
Debian	Rolling out	apt full-upgrade + check tracker
Fedora	Yes	dnf update kernel
AlmaLinux 8 / 9	Yes — in production	dnf clean metadata && dnf upgrade
RHEL	Yes	dnf update kernel
Rocky Linux	Rolling out	dnf update kernel
Arch Linux	Yes	pacman -Syu
Amazon Linux 2023	Yes	dnf update kernel
SUSE / openSUSE	Yes	zypper update kernel-default

---

A note on the modprobe mitigation in our earlier article

We included a modprobe blacklist command in our original Copy Fail article as the interim mitigation. That command is valid and works correctly on Debian-based systems including Ubuntu. However it does not work on RHEL-family distributions where algif_aead is compiled directly into the kernel. If you applied that mitigation on AlmaLinux, Rocky Linux, or RHEL, use the grubby command above instead and reboot to ensure you are actually protected.