Please don't rely on my judgement for this being safe for production, but after blacklisting the modules, the provided python exploit failed.
Check if the following are modules
grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r)
/etc/modprobe.d/blacklist-crypto-user-api.conf
"""
blacklist af_alg
blacklist algif_hash
blacklist algif_skcipher
blacklist algif_rng
blacklist algif_aead
install af_alg /bin/false
install algif_hash /bin/false
install algif_skcipher /bin/false
install algif_rng /bin/false
install algif_aead /bin/false
"""
update-initramfs -u
If iwd, or cryptsetup with certain non-default algorithms, isn't being used on the system, you should be fine. Not many programs use AF_ALG. It's possible there are others I'm not aware of, but it's quite rare.
To be clear, general-purpose Linux distros generally can't disable these kconfig options yet, due to these cases. But there are many Linux systems that simply don't need this functionality.
A good project for someone to work on would be to fix iwd and cryptsetup to always use userspace crypto, as they should.
is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?
No, dm-crypt just calls the kernel's crypto code directly.
I can’t comment on the ramifications, except to note that elsewhere in the thread this appears to not break anything (whether it makes userspace crypto a little less safe is academic, but that doesn’t matter if we have an easy local root shell), but I can verify the above fix does protect Ubuntu 24.04 from the exploit.
Just reboot after applying this change.
Or
Is it built as a module in most distros?
It is built as a module in Debian.
lsmod shows it is not loaded on any of the Trixie or Bookworm machines I have checked, Intel or AMD.