The Bleeping Computer link below mentions a potential remedy until a patch is ready.
https://www.bleepingcomputer.com/news/security/new-linux-cop...
The Bleeping Computer link below mentions a potential remedy until a patch is ready.
https://www.bleepingcomputer.com/news/security/new-linux-cop...
This workaround only applies to kernels with the impacted code compiled as a module. RHEL, Fedora, and Gentoo (we use a modified Fedora config) all are configured to build this in directly. Without a patch or config change (as Sam from Gentoo was alluding to), those distributions remain vulnerable.
There was some discussion on the GitHub issues about workarounds to disable it, even though it is baked in.
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues...
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues...
This worked as a mitigation on distros with the module compiled into the kernel: https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...
Basically: sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init
sudo reboot
F44 is safe as the kernel is greater than 6.18.22
For compiled-in kernels you can also work around it without rebooting via apparmor, seccomp or SELinux at the least, there may be eBPF or other methods too.
The potential remedy doesn't work on RedHat and derivatives because the affected code is not a module there but statically compiled in.