Ah, the #copyfail clickbait posts are coming.
-
@jwildeboer I'm confused somewhat by how distros didn't pick it up, looks like some don't have representatives on the kernel list?
@larsmb Could be. I guess the topic is a bit more complex. Some distros have `algif_aead` as module, so you can do the big hammer approach and `rmmod` it, other distros have `algif_aead` compiled into the kernel, so you need a more surgical approach, like the one I described. The surgical approach however has the advantage of working for both setups.
-
The TL;DR of #CopyFail in my opinion: Due to an unusual (I personally think irresponsible) disclosure, we sysadmins are now dealing with having to push out an immediate mitigation until the updated kernel packages become available. I am trying to help in a pragmatic way. This too will pass, but it also shows that running Linux servers comes with responsibilities to protect your machines and users.
4/4
@jwildeboer
Tbf whilst It's not great, its AT LEAST not remotely exploitable. Problematic if your workload runs untrusted stuff from external sources directly, absolutely. But likewise not quite as sky is falling as some have seemed to make it out to be. -
The TL;DR of #CopyFail in my opinion: Due to an unusual (I personally think irresponsible) disclosure, we sysadmins are now dealing with having to push out an immediate mitigation until the updated kernel packages become available. I am trying to help in a pragmatic way. This too will pass, but it also shows that running Linux servers comes with responsibilities to protect your machines and users.
4/4
ADDENDUM: Now also a blog post at https://jan.wildeboer.net/2026/05/PSA-CopyFail-CVE-2026-31431/
-
ADDENDUM: Now also a blog post at https://jan.wildeboer.net/2026/05/PSA-CopyFail-CVE-2026-31431/
@jwildeboer Nice! Btw wiki page is up: https://en.wikipedia.org/wiki/Copy_Fail
-
Ah, the #copyfail clickbait posts are coming. Here’s my contribution. On your Linux machine add
initcall_blacklist=algif_aead_init
to your kernel boot commandline (typically in grub). Reboot. You are now safe until the updated kernel packages become available. For distributions with the `grubby` command this is done as root with
# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
This mitigation comes courtesy of Red Hat. Our engineers keep you safe
1/4
This post is deleted! -
This post is deleted!
@Larvitz Edit: removed unhelpful cheap joke. I'm sorry. Will try harder to resist next time.
@jwildeboer -
Ah, the #copyfail clickbait posts are coming. Here’s my contribution. On your Linux machine add
initcall_blacklist=algif_aead_init
to your kernel boot commandline (typically in grub). Reboot. You are now safe until the updated kernel packages become available. For distributions with the `grubby` command this is done as root with
# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
This mitigation comes courtesy of Red Hat. Our engineers keep you safe
1/4
@jwildeboer since android runs with the linux kernel, is android also affected?
-
@Larvitz Edit: removed unhelpful cheap joke. I'm sorry. Will try harder to resist next time.
@jwildeboer -
@jwildeboer I'm sorry. You're right. Should have posted the cheap joke in my own feed.
@Larvitz -
@jwildeboer since android runs with the linux kernel, is android also affected?
@Sorro I don't know. Depends if `algif_aead` is compiled into the kernel or loaded as module, if it is present at all in Android kernels. If somebody has checked, please do reply.
-
Ah, the #copyfail clickbait posts are coming. Here’s my contribution. On your Linux machine add
initcall_blacklist=algif_aead_init
to your kernel boot commandline (typically in grub). Reboot. You are now safe until the updated kernel packages become available. For distributions with the `grubby` command this is done as root with
# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
This mitigation comes courtesy of Red Hat. Our engineers keep you safe
1/4
@jwildeboer what about those who cannot be downtimed to reboot?
-
@echopapa @larsmb @jwildeboer alma (yay the new centos model
) https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ -
Ah, the #copyfail clickbait posts are coming. Here’s my contribution. On your Linux machine add
initcall_blacklist=algif_aead_init
to your kernel boot commandline (typically in grub). Reboot. You are now safe until the updated kernel packages become available. For distributions with the `grubby` command this is done as root with
# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
This mitigation comes courtesy of Red Hat. Our engineers keep you safe
1/4
@jwildeboer
There's a special place in hell for security researchers who obfuscate their proof-of-concept exploit code. -
@jwildeboer since android runs with the linux kernel, is android also affected?
Are there any users on your Android phone who might take advantage of #copyfail ?
For single-user systems there is no problem, because it's not a remote exploit.
-
R relay@relay.infosec.exchange shared this topic
-
@jwildeboer @flxtr Deleted it. Sorry, could not help myself and thought "Galgenhumor" could help make this serious topic a bit more relaxed.
-
@jwildeboer what about those who cannot be downtimed to reboot?
@psyhackological They'll have to do a risk calculation. It is a local user exploit, so in most cases when you freeze the current software deployment, you should be safe until the kernel patches have arrived. In general, though, your contingency plans should ALWAYS make reboots possible.
-
@psyhackological They'll have to do a risk calculation. It is a local user exploit, so in most cases when you freeze the current software deployment, you should be safe until the kernel patches have arrived. In general, though, your contingency plans should ALWAYS make reboots possible.
@jwildeboer from what I read isn't this about removing kernel module? I think this keeps the system running without a reboot
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aeadDon't know what will happen when it reboots though so I would stick to your plan.
-
@jwildeboer from what I read isn't this about removing kernel module? I think this keeps the system running without a reboot
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aeadDon't know what will happen when it reboots though so I would stick to your plan.
@psyhackological Depends on your distribution. Some have it as module, some have it directly compiled into the kernel.
-
@Sorro I don't know. Depends if `algif_aead` is compiled into the kernel or loaded as module, if it is present at all in Android kernels. If somebody has checked, please do reply.
@jwildeboer @Sorro It's a bit hard to say because of the many, many flavors of Android in the wild, but it is very likely not affected for various reasons: by default, SELinux is configured to not allow alg_socket for sandboxed apps (see https://android.googlesource.com/platform/system/sepolicy/+/refs/tags/android-16.0.0_r4/private/app_neverallows.te#141), there are usually no suid binaries on Android, and algif_aead is usually not provided in the first place. Of course, a very old Android version might be affected, but in that case, you're open to various other exploits anyway...
-
@psyhackological Depends on your distribution. Some have it as module, some have it directly compiled into the kernel.
@jwildeboer we're on Ubuntu. Yiakes then... So it needs to be checked otherwise.
