On Mon, May 04, 2026 at 02:39:12PM +0000, Jon Kohler wrote:

quoted

On Apr 29, 2026, at 9:15 PM, Eric Biggers [off-list ref] wrote:

AF_ALG is almost completely unnecessary, and it exposes a massive attack
surface that hasn't been standing up to modern vulnerability discovery
tools.  The latest one even has its own website, providing a small
Python script that reliably roots most Linux distros: https://copy.fail/

This isn't sustainable, especially as LLMs have accelerated the rate the
vulnerabilities are coming in.  The effort that is being put into this
thing is vastly disproportional to the few programs that actually use
it, and those programs would be better served by userspace code anyway.

These issues have been noted in many mailing list discussions already.
But until now they haven't been reflected in the documentation or
kconfig menu itself, and the vulnerabilities are still coming in.

Let's go ahead and document the deprecation.

This isn't intended to change anything overnight.  After all, most Linux
distros won't be able to disable the kconfig options quite yet, mainly
because of iwd.  But this should create a bit more impetus for these
userspace programs to be fixed, and the documentation update should also
help prevent more users from appearing.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---

Quick passing observation
I noticed that when attempting to completely disable these Crypto APIs,
I was experiencing boot failures with fips=1 enabled systems.

Using 6.18-based kernel with an el9-based user space, I see the
following hang in the early boot console from dracut-pre-pivot:
  Check integrity of kernel
  libkcapi - Error: AF_ALG: socket syscall failed (errno: -97)
  Allocation of hmac(sha512) cipher failed (-97)

I haven't looked at every elX version, but at least in el9 and el10,
they use libkcapi-hmaccalc to provide sha512hmac, which dracut [1]
uses to calculate the HMAC value in do_fips().

Digging further, I was only able to disable RNG and AEAD APIs, but
not HASH and SKCIPHER APIs when FIPS was in the picture with el9++.

I’m not sure how other distros do the same, but this could be problematic
elsehwere if other distros went down the libkcapi route.

[1] https://github.com/dracutdevs/dracut/blob/059/modules.d/01fips/fips.sh#L167

That seems to be an implementation of FIPS 140-3's integrity self-check.
A few observations:

- It could easily use userspace SHA-512 code instead.  If including
  libcrypto.so in the "FIPS cryptographic boundary" would cause
  certification difficulties, then a sha512.c file could simply be added
  to 'libkcapi-hmaccalc' which is already in it.

- It's compatible with all of the proposed hardening.  It doesn't
  require zero-copy performance.  It runs as root, so it would be
  compatible with a capability check.  "hmac(sha512)" will need to be on
  the algorithm allowlist anyway for iwd.

- FIPS 140-3 might also allow it to be simplified to use a plain hash
  instead of pointlessly using HMAC with a fixed key.

Anyway, just another one of the long tail of odd users that could have
solved their problem in a better way.  This one is at least compatible
with the hardening that's being considered.

By the way, also on the topic of FIPS 140-3, some people do use AF_ALG
for ACVP (even though it's not all that great for that purpose, either).
But ACVP is a testing thing, not something that is needed on production
systems.  ACVP can just be run as root on a testing build; there's no
need to enable support for it in the actual production build.

- Eric