Mitigations for CopyFail linux local privilege escalation vulnerability

[fln]

A new local privilege escalation vulnerability named CopyFail CVE-2026-31431 was recently disclosed. It affects almost all of the systems and allows local user to get root access on the system. The Linux distribution maintainers are busy with releasing hot-fixes.

We are sharing an immediate mitigation for server administrators until we receive a fix from upstream.

For Debian, Ubuntu (and other Debian) based systems, the exploitable code is in a separate kernel module. So it is enough to just blacklist this module and unload it if it is already loaded. Commands:

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

For RHEL based systems, the explotable code is built-in. It can be disabled with extra kernel boot parameter and requires a server restart. Commands:

echo 'GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_DEFAULT} initcall_blacklist=algif_aead_init"' >> /etc/default/grub
grub2-mkconfig -o /etc/grub2.cfg
grubby --args initcall_blacklist=algif_aead_init --update-kernel=ALL --no-etc-grub-update
reboot

Note: the double approach first changing /etc/default/grub and then directly with grubby is to make sure same set of commands works on all RHEL systems and the change is persistent. The grubby command alone is enough to update the kernel arguments but they would be lost on the next kernel update.

 

[ccto]

F.Y.I. - After reboot, we may issue "cat /proc/cmdline" to double-verify.

 

[fln]

Note, the instructions for RHEL is updated, the call to grubby is extended with --no-etc-grub-update to avoid touching the /etc/default/grub file. Without this argument it can replace other custom kernel parameters that was added there before applying the mitigation commands.

 

[pat0]

Working fix for UEFI Alma systems:

echo 'GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_DEFAULT} initcall_blacklist=algif_aead_init"' >> /etc/default/grub
grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg
grubby --update-kernel=DEFAULT --args="initcall_blacklist=algif_aead_init"
reboot

 

[wedwards]

Note, the instructions for RHEL is updated, the call to grubby is extended with --no-etc-grub-update to avoid touching the /etc/default/grub file. Without this argument it can replace other custom kernel parameters that was added there before applying the mitigation commands.

FYI: doesn't seem available on all versions of Grubby:

[root@server ~]# grubby --args initcall_blacklist=algif_aead_init --update-kernel=ALL --no-etc-grub-update
grubby: bad argument --no-etc-grub-update: unknown option

This is a really old machine though (CentOS 7.9.2009, Grubby 8.28)

 

[pat0]

CentOS 7 with default 3.x kernel is not vulnerable to this.

 

[gate2vn]

For someone who doesn't want to reboot, can follow this tutorial

 

[HageHosting]

get this in console HELP services down

 

[zEitEr]

get this in console HELP services down

If your filesystem is in read-only mode, you will need to check the file system and/or replace disks.

 

[Daniel-Doggy]

Debian has released a new kernal patch for the expliot.

CVE-2026-31431

To install make sure you have the security updates repository enabled and after installing reboot the host. (New kernal is not used untill the host is rebooted.)

 

[exlhost]

Copy Fail (CVE-2026-31431) Patches Released

Update: Patched kernels are now in production2026-05-01 21:07 UTC — The patched kernels are now rolling out to production repositories/mirrors. You no longer need to enable the testing repo to get them. Just run: sudo dnf clean metadata && sudo dnf upgrade sudo reboot Most mirrors have a sync...

almalinux.org

 

[ccto]

AlmaLinux: Update: Patched kernels are now in production

Copy Fail (CVE-2026-31431) Patches Released

Update: Patched kernels are now in production2026-05-01 21:07 UTC — The patched kernels are now rolling out to production repositories/mirrors. You no longer need to enable the testing repo to get them. Just run: sudo dnf clean metadata && sudo dnf upgrade sudo reboot Most mirrors have a sync...

almalinux.org

 

[Hostking]

ok I just ran "yum update -y" on all servers and rebooted.

Also using Kernelcare may help I assume?

 

[gate2vn]

ok I just ran "yum update -y" on all servers and rebooted.

Also using Kernelcare may help I assume?

If you are using CloudLinux, make sure to check if lve is loaded after rebooting. I tested with one server when the kernel was in testing repo, and LVE was not working. Haven't tried again after they moved from testing to stable channel.

 

[mhsolutions]

Almalinux:

sudo dnf clean metadata
sudo dnf upgrade -y
sudo reboot

After reboot: check kernel version

uname -r

If same as:

• AlmaLinux 8 is patched in kernel-4.18.0-553.121.1.el8_10 and above
• AlmaLinux 9 is patched in kernel-5.14.0-611.49.2.el9_7 and above
• AlmaLinux 10 is patched in kernel-6.12.0-124.52.2.el10_1 and above
• AlmaLinux Kitten 10 is patched in kernel-6.12.0-225.el10 and above

Copy Fail (CVE-2026-31431) Patches Released

Update: Patched kernels are now in production2026-05-01 21:07 UTC — The patched kernels are now rolling out to production repositories/mirrors. You no longer need to enable the testing repo to get them. Just run: sudo dnf clean metadata && sudo dnf upgrade sudo reboot Most mirrors have a sync...

almalinux.org