[buredoranna]

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)

If they are, you can try blacklisting them

  /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

Can anyone comment on the ramifications this?

[ebiggers]

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.

[400thecat]

is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?

[ebiggers]

No, dm-crypt just calls the kernel's crypto code directly.

[strenholme]

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.

[Milpotel]

Or

  zgrep CONFIG_CRYPTO_USER_API /proc/config.gz

[globular-toast]

Is it built as a module in most distros?

[dsr_]

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.

[tomxor]

FYI it's dynamically loaded on demand, so lsmod will show it after you try run the exploit, or you can explicitly load it with:

  modprobe algif_aead

The following mitigation (from the article) does work for Debian 12 and 13, I've tested this:

  echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  rmmod algif_aead 2>/dev/null || true

First line blocks it from loading, second line is unloading it if it's already been loaded. You can test with the same "modprobe algif_aead".

[dundarious]

The point of noting whether it is loaded on their machine or not, is presumably to indicate that it is not normally loaded (for them), so disabling it to block the exploit should have no impact (for them).

[globular-toast]

It was loaded on my Ubuntu system so I wonder what used it.

[alexdevphp]

As I understands any program code can use that socket to write to page cache memory and modify any main program. Even php code can be written for that. So it is serious problem if there is other security hole on web server.

[PunchyHamster]

over 500 servers with very varied workload i manage didn't had this module loaded so my guess is "near zero"

also only algif_aead is vulnerable