Ah, the #copyfail clickbait posts are coming.
-
@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.
-
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 thanks for the post. To add, also keep on eye on which distro have patched the mitigation, Fedora patched it a week ago or so iirc, Fedora 44 doesn’t have the exploit at all. Neither does anything about running the 7.x kernel.
-
@jwildeboer thanks for the post. To add, also keep on eye on which distro have patched the mitigation, Fedora patched it a week ago or so iirc, Fedora 44 doesn’t have the exploit at all. Neither does anything about running the 7.x kernel.
@sstendahl Yes, that's in the second post of my thread, with links
https://social.wildeboer.net/@jwildeboer/116503831839617808 -
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.
@caravantraveller @jwildeboer ooh, i didnt really understand much about the exploit so i thought it was a remote exploit. that's a relief for me even for my linux laptop
thanks for telling me!
-
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 I think this only works when the module is builtin (as on RHEL, but not many others).
-
@jwildeboer I think this only works when the module is builtin (as on RHEL, but not many others).
@leah It should still work, as initcall_blacklist on init functions works regardless of it being a module or compiled in. I don't have a machine with it built as a module at hand, nor do I have the time to spin one up and check. If somebody else could help here and share the result, much appreciated.
-
R relay@relay.mycrowd.ca shared this topic
