They aren’t available on all releases - the people that found the issue didn’t really follow responsible disclosure, so distros didn’t have time to fix it
They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out
Giving a better solution is certainly useful.
I’d used initcall_debug before, but not initcall_blacklist
I’m working off the knowledge that OP is using a rolling release, so is likely fixed by that for them. (Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I’d expect Bazzite to have it too. If they’re using Debian Sid/Testing, it’s both fixed and a module)
If you’re using something else, this eBPF filter is probably your best bet https://github.com/Dabbleam/CVE-2026-31431-mitigation
Yeah… It seems like they only reached out to the kernel, and not to any distros…
They also disclosed after 37 days rather than the more standard 90 days for everyone to patch
Check uname -r
If you’re on 6.19.12 or newer (7.0.1 if they’ve already bumped to 7) you’re definitely safe
For others, it looks fixed in 6.18.22 6.12.85 6.6.137 6.1.170 5.15.204
If you don’t have a safe kernel,
A better solution referenced below than a module blacklist is to set initcall_blacklist=algif_aead_init in your kernel boot parameters. There is not a generic way to do this across distros, so you will need to look it up for your case
~~If you don’t have the updated kernel, you can
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf and reboot.
That ensures the buggy module cannot be loaded until you have an updated kernel~~
The ones I was watching look like there’s an update as of an hour ago, but there wasn’t at the time of the post
Need to check Raspbian still, being on self hosting