Mitigating CVE-2026-31431 (Linux based systems) Print

  • 1

How to Mitigate CVE-2026-31431 ("Copy Fail") on Linux Servers

Last updated: May 1, 2026

What is Copy Fail?

CVE-2026-31431, nicknamed "Copy Fail", is a high-severity local privilege escalation vulnerability in the Linux kernel (CVSS 7.8). It affects virtually every mainstream Linux distribution shipped since 2017.

The flaw lives in the kernel's algif_aead cryptographic interface. By chaining an AF_ALG socket call with splice(), an unprivileged local user can perform a controlled 4-byte write into the page cache of any readable file — including setuid-root binaries like /usr/bin/su. A working 732-byte Python exploit is publicly available and works reliably across distributions without timing or race conditions.

Am I affected?

If you run any Linux distribution with a kernel released between 2017 and the patch (April 2026), yes. This includes:

  • CentOS 7, CentOS Stream 8/9/10
  • RHEL 7/8/9/10, AlmaLinux, Rocky Linux, CloudLinux
  • Ubuntu 18.04, 20.04, 22.04, 24.04 (Ubuntu 26.04+ is not affected)
  • Debian 10, 11, 12

The vulnerability requires local code execution — it cannot be exploited remotely on its own. However, in shared hosting, multi-tenant, container, or CI environments, this is a critical risk because any user with shell access (including via a compromised website) can escalate to root.

Quick check: is my server affected?

Run this on any Linux server:

uname -r
grep -E 'authencesn|algif_aead' /proc/crypto

If the kernel changelog does not yet reference CVE-2026-31431, the server is vulnerable and needs either a patched kernel or the mitigation below.

How to fix

You have two options:

  1. Install a patched kernel from your distribution and reboot (preferred when available).
  2. Apply the mitigation below, which disables the vulnerable algif_aead interface entirely. This is fully effective and only requires a reboot.

The mitigation has no impact on dm-crypt/LUKS, kTLS, IPsec, OpenSSL, GnuTLS, NSS, or SSH. Only applications that explicitly use the AF_ALG userspace crypto API for AEAD operations (rare on standard servers) are affected.


Mitigation for RPM-based systems (CentOS / RHEL / AlmaLinux / Rocky Linux / CloudLinux)

Applies to: CentOS 7, CentOS Stream 8/9/10, RHEL 7/8/9/10, AlmaLinux 8/9/10, Rocky Linux 8/9/10, CloudLinux 7/8/9/10.

Step 1 — Add the kernel boot parameter:

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

Step 2 — Verify the parameter is set:

sudo grubby --info=DEFAULT | grep args

You should see initcall_blacklist=algif_aead_init in the output.

Step 3 — Reboot the server:

sudo reboot

Step 4 — Verify mitigation is active after reboot:

cat /proc/cmdline | grep initcall_blacklist
grep -E 'authencesn|algif_aead|af_alg' /proc/crypto
dmesg | grep -i 'blacklisting initcall'

Expected results:

  • The first command should show the parameter.
  • The second command should return no output (empty).
  • The third command should show blacklisting initcall algif_aead_init.

If all three checks pass, the mitigation is fully active.


Mitigation for Debian / Ubuntu-based systems

Applies to: Debian 10/11/12, Ubuntu 18.04, 20.04, 22.04, 24.04.

Step 1 — Create the modprobe blacklist:

sudo tee /etc/modprobe.d/disable-algif-aead.conf > /dev/null <<'EOF'
install algif_aead /bin/false
blacklist algif_aead
EOF

Step 2 — Back up the GRUB config:

sudo cp /etc/default/grub /etc/default/grub.backup-copyfail

Step 3 — Add the kernel boot parameter:

sudo sed -i 's|^GRUB_CMDLINE_LINUX="\(.*\)"|GRUB_CMDLINE_LINUX="\1 initcall_blacklist=algif_aead_init"|' /etc/default/grub

Step 4 — Verify the parameter was added:

grep GRUB_CMDLINE_LINUX /etc/default/grub

You should see initcall_blacklist=algif_aead_init in the output.

Step 5 — Regenerate the GRUB config:

sudo update-grub

If update-grub is not available (minimal Debian), use instead:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Step 6 — Update initramfs:

sudo update-initramfs -u

Step 7 — Reboot the server:

sudo reboot

Step 8 — Verify mitigation is active after reboot:

cat /proc/cmdline | grep initcall_blacklist
lsmod | grep algif_aead
grep -E 'authencesn|algif_aead|af_alg' /proc/crypto
dmesg | grep -i 'blacklisting initcall'

Expected results:

  • The first command should show the parameter.
  • The second and third commands should return no output (empty).
  • The fourth command should show blacklisting initcall algif_aead_init.

Removing the mitigation after installing a patched kernel

Once your distribution releases a kernel that includes the official fix for CVE-2026-31431, install it and remove the mitigation. There is no rush — the mitigation can stay in place indefinitely without harm.

For RPM-based systems:

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

(On CentOS 7, replace dnf with yum.)

For Debian/Ubuntu systems:

sudo apt update && sudo apt upgrade
sudo rm /etc/modprobe.d/disable-algif-aead.conf
sudo sed -i 's| initcall_blacklist=algif_aead_init||' /etc/default/grub
sudo update-grub
sudo update-initramfs -u
sudo reboot

Verify the patched kernel is running:

uname -r

Compare against your distribution's official patched kernel version. For AlmaLinux 9, this is 5.14.0-611.49.2.el9_7 or higher; for AlmaLinux 8, 4.18.0-553.121.1.el8_10 or higher. Other distributions: check the official security advisory pages.


References

If you need assistance applying this mitigation to your server, please open a support ticket.


Was this answer helpful?

« Back