[PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Eric Biggers]

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>
---

This patch is targeting crypto/master

 Documentation/crypto/userspace-if.rst | 82 ++++++++++++++++++++-------
 crypto/Kconfig                        | 69 ++++++++++++++++------
 2 files changed, 113 insertions(+), 38 deletions(-)

diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
index 021759198fe7..c39f5c79a5b7 100644
--- a/Documentation/crypto/userspace-if.rst
+++ b/Documentation/crypto/userspace-if.rst
@@ -2,30 +2,72 @@ User Space Interface
 ====================
 
 Introduction
 ------------
 
-The concepts of the kernel crypto API visible to kernel space is fully
-applicable to the user space interface as well. Therefore, the kernel
-crypto API high level discussion for the in-kernel use cases applies
-here as well.
-
-The major difference, however, is that user space can only act as a
-consumer and never as a provider of a transformation or cipher
-algorithm.
-
-The following covers the user space interface exported by the kernel
-crypto API. A working example of this description is libkcapi that can
-be obtained from [1]. That library can be used by user space
-applications that require cryptographic services from the kernel.
-
-Some details of the in-kernel kernel crypto API aspects do not apply to
-user space, however. This includes the difference between synchronous
-and asynchronous invocations. The user space API call is fully
-synchronous.
-
-[1] https://www.chronox.de/libkcapi/index.html
+AF_ALG provides unprivileged userspace programs access to arbitrary hash,
+symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode
+code.
+
+AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010,
+most kernel developers now consider it to be a mistake.
+
+AF_ALG continues to be supported only for backwards compatibility. On systems
+where no programs using AF_ALG remain, the support for it should be disabled by
+disabling ``CONFIG_CRYPTO_USER_API_*``.
+
+Deprecation
+-----------
+
+AF_ALG was originally intended to provide userspace programs access to crypto
+accelerators that they wouldn't otherwise have access to.
+
+However, that capability turned out to not be useful on very many systems. More
+significantly, the actual implementation exposes a vastly greater amount of
+functionality than that. It actually provides access to all software algorithms.
+
+This includes arbitrary compositions of different algorithms created via a
+complex template system, as well as algorithms that only make sense as internal
+implementation details of other algorithms. It also includes full zero-copy
+support, which is difficult for the kernel to implement securely.
+
+Ultimately, these algorithms are just math computations. They use the same
+instructions that userspace programs already have access to, just accessed in a
+much more convoluted and less efficient way.
+
+Indeed, userspace code is nearly always what is being used anyway. These same
+algorithms are widely implemented in userspace crypto libraries.
+
+Meanwhile, AF_ALG hasn't been withstanding modern vulnerability discovery tools
+such as syzbot and large language models. It receives a steady stream of CVEs.
+Some of the examples include:
+
+- CVE-2026-31677
+- CVE-2026-31431 (https://copy.fail)
+- CVE-2025-38079
+- CVE-2025-37808
+- CVE-2024-26824
+- CVE-2022-48781
+- CVE-2019-8912
+- CVE-2018-14619
+- CVE-2017-18075
+- CVE-2017-17806
+- CVE-2017-17805
+- CVE-2016-10147
+- CVE-2015-8970
+- CVE-2015-3331
+- CVE-2014-9644
+- CVE-2013-7421
+- CVE-2011-4081
+
+It is recommended that, whenever possible, userspace programs be migrated to
+userspace crypto code (which again, is what is normally used anyway) and
+``CONFIG_CRYPTO_USER_API_*`` be disabled.  On systems that use SELinux, SELinux
+can also be used to restrict the use of AF_ALG to trusted programs.
+
+The remainder of this documentation provides the historical documentation for
+the deprecated AF_ALG interface.
 
 User Space API General Remarks
 ------------------------------
 
 The kernel crypto API is accessible from user space. Currently, the
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 103d1f58cb7c..6cd1c478d4be 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1278,48 +1278,72 @@ config CRYPTO_DF80090A
 	tristate
 	select CRYPTO_AES
 	select CRYPTO_CTR
 
 endmenu
-menu "Userspace interface"
+menu "Userspace interface (deprecated)"
 
 config CRYPTO_USER_API
 	tristate
 
 config CRYPTO_USER_API_HASH
-	tristate "Hash algorithms"
+	tristate "Hash algorithms (deprecated)"
 	depends on NET
 	select CRYPTO_HASH
 	select CRYPTO_USER_API
 	help
-	  Enable the userspace interface for hash algorithms.
+	  Enable the AF_ALG userspace interface for hash algorithms.  This
+	  provides unprivileged userspace programs access to arbitrary hash
+	  algorithms implemented in the kernel's privileged execution context.
 
-	  See Documentation/crypto/userspace-if.rst and
-	  https://www.chronox.de/libkcapi/html/index.html
+	  This interface is deprecated and is supported only for backwards
+	  compatibility.  It regularly has vulnerabilities, and the capabilities
+	  it provides are redundant with userspace crypto libraries.
+
+	  Enable this only if needed for support for a program that hasn't yet
+	  been converted to userspace crypto, for example iwd.
+
+	  See also Documentation/crypto/userspace-if.rst
 
 config CRYPTO_USER_API_SKCIPHER
-	tristate "Symmetric key cipher algorithms"
+	tristate "Symmetric key cipher algorithms (deprecated)"
 	depends on NET
 	select CRYPTO_SKCIPHER
 	select CRYPTO_USER_API
 	help
-	  Enable the userspace interface for symmetric key cipher algorithms.
+	  Enable the AF_ALG userspace interface for symmetric key algorithms.
+	  This provides unprivileged userspace programs access to arbitrary
+	  symmetric key algorithms implemented in the kernel's privileged
+	  execution context.
+
+	  This interface is deprecated and is supported only for backwards
+	  compatibility.  It regularly has vulnerabilities, and the capabilities
+	  it provides are redundant with userspace crypto libraries.
+
+	  Enable this only if needed for support for a program that hasn't yet
+	  been converted to userspace crypto, for example iwd, or cryptsetup
+	  with certain algorithms.
 
-	  See Documentation/crypto/userspace-if.rst and
-	  https://www.chronox.de/libkcapi/html/index.html
+	  See also Documentation/crypto/userspace-if.rst
 
 config CRYPTO_USER_API_RNG
-	tristate "RNG (random number generator) algorithms"
+	tristate "Random number generation algorithms (deprecated)"
 	depends on NET
 	select CRYPTO_RNG
 	select CRYPTO_USER_API
 	help
-	  Enable the userspace interface for RNG (random number generator)
-	  algorithms.
+	  Enable the AF_ALG userspace interface for random number generation
+	  (RNG) algorithms.  This provides unprivileged userspace programs
+	  access to arbitrary RNG algorithms implemented in the kernel's
+	  privileged execution context.
 
-	  See Documentation/crypto/userspace-if.rst and
-	  https://www.chronox.de/libkcapi/html/index.html
+	  This interface is deprecated and is supported only for backwards
+	  compatibility.  It regularly has vulnerabilities, and the capabilities
+	  it provides are redundant with userspace crypto libraries as well as
+	  the normal kernel RNG (e.g., /dev/urandom and getrandom(2)).
+
+	  See also Documentation/crypto/userspace-if.rst
 
 config CRYPTO_USER_API_RNG_CAVP
 	bool "Enable CAVP testing of DRBG"
 	depends on CRYPTO_USER_API_RNG && CRYPTO_DRBG
 	help
@@ -1330,20 +1354,29 @@ config CRYPTO_USER_API_RNG_CAVP
 
 	  This should only be enabled for CAVP testing. You should say
 	  no unless you know what this is.
 
 config CRYPTO_USER_API_AEAD
-	tristate "AEAD cipher algorithms"
+	tristate "AEAD cipher algorithms (deprecated)"
 	depends on NET
 	select CRYPTO_AEAD
 	select CRYPTO_SKCIPHER
 	select CRYPTO_USER_API
 	help
-	  Enable the userspace interface for AEAD cipher algorithms.
+	  Enable the AF_ALG userspace interface for authenticated encryption
+	  with associated data (AEAD) algorithms.  This provides unprivileged
+	  userspace programs access to arbitrary AEAD algorithms implemented in
+	  the kernel's privileged execution context.
+
+	  This interface is deprecated and is supported only for backwards
+	  compatibility.  It regularly has vulnerabilities, and the capabilities
+	  it provides are redundant with userspace crypto libraries.
+
+	  Enable this only if needed for support for a program that hasn't yet
+	  been converted to userspace crypto, for example iwd.
 
-	  See Documentation/crypto/userspace-if.rst and
-	  https://www.chronox.de/libkcapi/html/index.html
+	  See also Documentation/crypto/userspace-if.rst
 
 config CRYPTO_USER_API_ENABLE_OBSOLETE
 	bool "Obsolete cryptographic algorithms"
 	depends on CRYPTO_USER_API
 	default y

base-commit: 57b8e2d666a31fa201432d58f5fe3469a0dd83ba
-- 
2.54.0

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Herbert Xu]

On Wed, Apr 29, 2026 at 06:15:44PM -0700, Eric Biggers 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>

What about the exposure of akcipher through security/keys/keyctl_pkey.c?

There isn't even a Kconfig option to disable that user-space API.
If module signatures are enabled then this automatically gets added
to the kernel:

MODULE_SIG -> MODULE_SIG_FORMAT -> SYSTEM_DATA_VERIFICATION ->
KEYS + ASYMMETRIC_KEY_TYPE

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Eric Biggers]

On Thu, Apr 30, 2026 at 10:05:00AM +0800, Herbert Xu wrote:
> On Wed, Apr 29, 2026 at 06:15:44PM -0700, Eric Biggers 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>
> 
> What about the exposure of akcipher through security/keys/keyctl_pkey.c?
> 
> There isn't even a Kconfig option to disable that user-space API.
> If module signatures are enabled then this automatically gets added
> to the kernel:
> 
> MODULE_SIG -> MODULE_SIG_FORMAT -> SYSTEM_DATA_VERIFICATION ->
> KEYS + ASYMMETRIC_KEY_TYPE

Yes, that would be a different patch, but KEYCTL_PKEY_* have a very
similar issue.  That should have a kconfig option added too.

I believe iwd is the main (or even only?) user there, as well.

- Eric

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Jon Kohler]

> On Apr 29, 2026, at 9:15 PM, Eric Biggers <ebiggers@kernel.org> 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

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Eric Biggers]

On Mon, May 04, 2026 at 02:39:12PM +0000, Jon Kohler wrote:
> > On Apr 29, 2026, at 9:15 PM, Eric Biggers <ebiggers@kernel.org> 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

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Jeff Barnes]

On May 4 2026, at 10:39 am, Jon Kohler <jon@nutanix.com> wrote:

>  
> 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)

One thing that for certain that would cause this panic is the sha512hmac
binary that does the fips integrity check. On many distros this check is
called, for example by dracut among others, during initramfs to check
the integrity of the kernel before any crypto is used. On failure, the
kernel won't finish boot.

sha512hmac is a binary shipped with kcapitools. It uses libkcapi.

sha512hmac -> libkcapi -> AF_ALG.

Is there a planned replacement for this integrity check? I don't know of
anybody doing this for FIPS yet, but is there a case where IMA / EVM
could be a workaround?

Regards,
Jeff

>  
> 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
>  
>

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Jeff Barnes]

On May 4 2026, at 1:39 pm, Eric Biggers <ebiggers@kernel.org> wrote:
>  
> 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.

Indeed expanding the crypto boundary to include libcrypto.so would cause
certification difficulties, it would mean certifying all of libcrypto.so
with the kernel. There *may* be a case for saying that it is outside the
module boundary but only if:

    * The integrity mechanism is clearly external
    * The cryptographic module refuses to operate unless integrity is confirmed
    * The trust relationship is clearly documented

I don't see how this could be justified cleanly without significant pushback.

>  
> - 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.

FIPS 140‑3 (via ISO/IEC 19790) draws a hard distinction between:
    * Integrity checking (cryptographic protection)
    * Integrity measurement (detection only)

A plain hash provides no protection against an attacker who can modify
both the object and its reference hash.

>  
> 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.

Agreed it's not a good use case. Unless/until pkcs1 is supported, I
don't see how you can use it for all of the test cases. Plus as
evidenced by Ubuntu's new cert, it requires validating the library.

>  
> - Eric
>

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Eric Biggers]

On Mon, May 04, 2026 at 02:12:11PM -0400, Jeff Barnes wrote:
> A plain hash provides no protection against an attacker who can modify
> both the object and its reference hash.

Same with the HMAC, because in the FIPS integrity check the key isn't
secret.  You can find the key used by the sha512hmac binary here:
https://github.com/smuellerDD/libkcapi/blob/master/apps/kcapi-hasher.c#L125

- Eric

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Simo Sorce]

On Mon, 2026-05-04 at 14:12 -0400, Jeff Barnes wrote:
> 
> On May 4 2026, at 1:39 pm, Eric Biggers <ebiggers@kernel.org> wrote:
> >  
> > 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.
> 
> Indeed expanding the crypto boundary to include libcrypto.so would cause
> certification difficulties, it would mean certifying all of libcrypto.so
> with the kernel. There *may* be a case for saying that it is outside the
> module boundary but only if:
> 
>     * The integrity mechanism is clearly external
>     * The cryptographic module refuses to operate unless integrity is confirmed
>     * The trust relationship is clearly documented
> 
> I don't see how this could be justified cleanly without significant pushback.
> 
> >  
> > - 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.
> 
> FIPS 140‑3 (via ISO/IEC 19790) draws a hard distinction between:
>     * Integrity checking (cryptographic protection)
>     * Integrity measurement (detection only)
> 
> A plain hash provides no protection against an attacker who can modify
> both the object and its reference hash.

The integrity mechanism is not build to detect adversarial tampering
(at least at level 1), that is not its purpose.

That said a HMAC is just a hash with a secret key in the mix, it does
not change the conditions wrt Hash if the key is known.

 
> > 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.
> 
> Agreed it's not a good use case. Unless/until pkcs1 is supported, I
> don't see how you can use it for all of the test cases. Plus as
> evidenced by Ubuntu's new cert, it requires validating the library.

Of course it requires validating the library, validating the
cryptography implementation is what FIPS is for. libcrypto.so can never
be outside the boundary, unless you turn it off at runtime ...

The problems are rather that libcrypto is not instrumented to enforce
KAT tests are executed before it allows operation (crypto-API did this
via test manager) and does not provide an indicator (or blocks)
unapproved algorithms ...

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Herbert Xu]

On Wed, Apr 29, 2026 at 06:15:44PM -0700, Eric Biggers 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>
> ---
> 
> This patch is targeting crypto/master
> 
>  Documentation/crypto/userspace-if.rst | 82 ++++++++++++++++++++-------
>  crypto/Kconfig                        | 69 ++++++++++++++++------
>  2 files changed, 113 insertions(+), 38 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Andy Lutomirski]

> On Apr 29, 2026, at 6:19 PM, Eric Biggers <ebiggers@kernel.org> 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/

How about adding a configuration option, defaulted on, that requires
capable(CAP_SYS_ADMIN) to create the socket (and maybe also to bind /
connect it).  And a sysctl to allow the administrator to override this
in the unlikely event that it’s needed.

IIRC cryptsetup used to and maybe even still does require these
sockets sometimes and this would let it keep working.  And there's all
the FIPS stuff downthread.


>
> 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>
> ---
>
> This patch is targeting crypto/master
>
> Documentation/crypto/userspace-if.rst | 82 ++++++++++++++++++++-------
> crypto/Kconfig                        | 69 ++++++++++++++++------
> 2 files changed, 113 insertions(+), 38 deletions(-)
>
> diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
> index 021759198fe7..c39f5c79a5b7 100644
> --- a/Documentation/crypto/userspace-if.rst
> +++ b/Documentation/crypto/userspace-if.rst
> @@ -2,30 +2,72 @@ User Space Interface
> ====================
>
> Introduction
> ------------
>
> -The concepts of the kernel crypto API visible to kernel space is fully
> -applicable to the user space interface as well. Therefore, the kernel
> -crypto API high level discussion for the in-kernel use cases applies
> -here as well.
> -
> -The major difference, however, is that user space can only act as a
> -consumer and never as a provider of a transformation or cipher
> -algorithm.
> -
> -The following covers the user space interface exported by the kernel
> -crypto API. A working example of this description is libkcapi that can
> -be obtained from [1]. That library can be used by user space
> -applications that require cryptographic services from the kernel.
> -
> -Some details of the in-kernel kernel crypto API aspects do not apply to
> -user space, however. This includes the difference between synchronous
> -and asynchronous invocations. The user space API call is fully
> -synchronous.
> -
> -[1] https://www.chronox.de/libkcapi/index.html
> +AF_ALG provides unprivileged userspace programs access to arbitrary hash,
> +symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode
> +code.
> +
> +AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010,
> +most kernel developers now consider it to be a mistake.
> +
> +AF_ALG continues to be supported only for backwards compatibility. On systems
> +where no programs using AF_ALG remain, the support for it should be disabled by
> +disabling ``CONFIG_CRYPTO_USER_API_*``.
> +
> +Deprecation
> +-----------
> +
> +AF_ALG was originally intended to provide userspace programs access to crypto
> +accelerators that they wouldn't otherwise have access to.
> +
> +However, that capability turned out to not be useful on very many systems. More
> +significantly, the actual implementation exposes a vastly greater amount of
> +functionality than that. It actually provides access to all software algorithms.
> +
> +This includes arbitrary compositions of different algorithms created via a
> +complex template system, as well as algorithms that only make sense as internal
> +implementation details of other algorithms. It also includes full zero-copy
> +support, which is difficult for the kernel to implement securely.
> +
> +Ultimately, these algorithms are just math computations. They use the same
> +instructions that userspace programs already have access to, just accessed in a
> +much more convoluted and less efficient way.
> +
> +Indeed, userspace code is nearly always what is being used anyway. These same
> +algorithms are widely implemented in userspace crypto libraries.
> +
> +Meanwhile, AF_ALG hasn't been withstanding modern vulnerability discovery tools
> +such as syzbot and large language models. It receives a steady stream of CVEs.
> +Some of the examples include:
> +
> +- CVE-2026-31677
> +- CVE-2026-31431 (https://copy.fail)
> +- CVE-2025-38079
> +- CVE-2025-37808
> +- CVE-2024-26824
> +- CVE-2022-48781
> +- CVE-2019-8912
> +- CVE-2018-14619
> +- CVE-2017-18075
> +- CVE-2017-17806
> +- CVE-2017-17805
> +- CVE-2016-10147
> +- CVE-2015-8970
> +- CVE-2015-3331
> +- CVE-2014-9644
> +- CVE-2013-7421
> +- CVE-2011-4081
> +
> +It is recommended that, whenever possible, userspace programs be migrated to
> +userspace crypto code (which again, is what is normally used anyway) and
> +``CONFIG_CRYPTO_USER_API_*`` be disabled.  On systems that use SELinux, SELinux
> +can also be used to restrict the use of AF_ALG to trusted programs.
> +
> +The remainder of this documentation provides the historical documentation for
> +the deprecated AF_ALG interface.
>
> User Space API General Remarks
> ------------------------------
>
> The kernel crypto API is accessible from user space. Currently, the
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 103d1f58cb7c..6cd1c478d4be 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -1278,48 +1278,72 @@ config CRYPTO_DF80090A
>    tristate
>    select CRYPTO_AES
>    select CRYPTO_CTR
>
> endmenu
> -menu "Userspace interface"
> +menu "Userspace interface (deprecated)"
>
> config CRYPTO_USER_API
>    tristate
>
> config CRYPTO_USER_API_HASH
> -    tristate "Hash algorithms"
> +    tristate "Hash algorithms (deprecated)"
>    depends on NET
>    select CRYPTO_HASH
>    select CRYPTO_USER_API
>    help
> -      Enable the userspace interface for hash algorithms.
> +      Enable the AF_ALG userspace interface for hash algorithms.  This
> +      provides unprivileged userspace programs access to arbitrary hash
> +      algorithms implemented in the kernel's privileged execution context.
>
> -      See Documentation/crypto/userspace-if.rst and
> -      https://www.chronox.de/libkcapi/html/index.html
> +      This interface is deprecated and is supported only for backwards
> +      compatibility.  It regularly has vulnerabilities, and the capabilities
> +      it provides are redundant with userspace crypto libraries.
> +
> +      Enable this only if needed for support for a program that hasn't yet
> +      been converted to userspace crypto, for example iwd.
> +
> +      See also Documentation/crypto/userspace-if.rst
>
> config CRYPTO_USER_API_SKCIPHER
> -    tristate "Symmetric key cipher algorithms"
> +    tristate "Symmetric key cipher algorithms (deprecated)"
>    depends on NET
>    select CRYPTO_SKCIPHER
>    select CRYPTO_USER_API
>    help
> -      Enable the userspace interface for symmetric key cipher algorithms.
> +      Enable the AF_ALG userspace interface for symmetric key algorithms.
> +      This provides unprivileged userspace programs access to arbitrary
> +      symmetric key algorithms implemented in the kernel's privileged
> +      execution context.
> +
> +      This interface is deprecated and is supported only for backwards
> +      compatibility.  It regularly has vulnerabilities, and the capabilities
> +      it provides are redundant with userspace crypto libraries.
> +
> +      Enable this only if needed for support for a program that hasn't yet
> +      been converted to userspace crypto, for example iwd, or cryptsetup
> +      with certain algorithms.
>
> -      See Documentation/crypto/userspace-if.rst and
> -      https://www.chronox.de/libkcapi/html/index.html
> +      See also Documentation/crypto/userspace-if.rst
>
> config CRYPTO_USER_API_RNG
> -    tristate "RNG (random number generator) algorithms"
> +    tristate "Random number generation algorithms (deprecated)"
>    depends on NET
>    select CRYPTO_RNG
>    select CRYPTO_USER_API
>    help
> -      Enable the userspace interface for RNG (random number generator)
> -      algorithms.
> +      Enable the AF_ALG userspace interface for random number generation
> +      (RNG) algorithms.  This provides unprivileged userspace programs
> +      access to arbitrary RNG algorithms implemented in the kernel's
> +      privileged execution context.
>
> -      See Documentation/crypto/userspace-if.rst and
> -      https://www.chronox.de/libkcapi/html/index.html
> +      This interface is deprecated and is supported only for backwards
> +      compatibility.  It regularly has vulnerabilities, and the capabilities
> +      it provides are redundant with userspace crypto libraries as well as
> +      the normal kernel RNG (e.g., /dev/urandom and getrandom(2)).
> +
> +      See also Documentation/crypto/userspace-if.rst
>
> config CRYPTO_USER_API_RNG_CAVP
>    bool "Enable CAVP testing of DRBG"
>    depends on CRYPTO_USER_API_RNG && CRYPTO_DRBG
>    help
> @@ -1330,20 +1354,29 @@ config CRYPTO_USER_API_RNG_CAVP
>
>      This should only be enabled for CAVP testing. You should say
>      no unless you know what this is.
>
> config CRYPTO_USER_API_AEAD
> -    tristate "AEAD cipher algorithms"
> +    tristate "AEAD cipher algorithms (deprecated)"
>    depends on NET
>    select CRYPTO_AEAD
>    select CRYPTO_SKCIPHER
>    select CRYPTO_USER_API
>    help
> -      Enable the userspace interface for AEAD cipher algorithms.
> +      Enable the AF_ALG userspace interface for authenticated encryption
> +      with associated data (AEAD) algorithms.  This provides unprivileged
> +      userspace programs access to arbitrary AEAD algorithms implemented in
> +      the kernel's privileged execution context.
> +
> +      This interface is deprecated and is supported only for backwards
> +      compatibility.  It regularly has vulnerabilities, and the capabilities
> +      it provides are redundant with userspace crypto libraries.
> +
> +      Enable this only if needed for support for a program that hasn't yet
> +      been converted to userspace crypto, for example iwd.
>
> -      See Documentation/crypto/userspace-if.rst and
> -      https://www.chronox.de/libkcapi/html/index.html
> +      See also Documentation/crypto/userspace-if.rst
>
> config CRYPTO_USER_API_ENABLE_OBSOLETE
>    bool "Obsolete cryptographic algorithms"
>    depends on CRYPTO_USER_API
>    default y
>
> base-commit: 57b8e2d666a31fa201432d58f5fe3469a0dd83ba
> --
> 2.54.0
>
>

Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Eric Biggers]

On Tue, May 05, 2026 at 04:17:18PM -0700, Andy Lutomirski wrote:
> > On Apr 29, 2026, at 6:19 PM, Eric Biggers <ebiggers@kernel.org> 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/
> 
> How about adding a configuration option, defaulted on, that requires
> capable(CAP_SYS_ADMIN) to create the socket (and maybe also to bind /
> connect it).  And a sysctl to allow the administrator to override this
> in the unlikely event that it’s needed.
> 
> IIRC cryptsetup used to and maybe even still does require these
> sockets sometimes and this would let it keep working.  And there's all
> the FIPS stuff downthread.

Yes, I'd like to add a default-on requirement to hold a capability in
the initial user namespace.  We're trying to figure out the details.

It sounds like iwd runs with CAP_NET_ADMIN, not necessarily
CAP_SYS_ADMIN.  So it may need to be:

    has_capability_noaudit(current, CAP_NET_ADMIN) || capable(CAP_SYS_ADMIN)

iwd is being discussed in the thread
https://lore.kernel.org/linux-crypto/bcbbef00-5881-421b-8892-7be6c04b832d@gmail.com/

cryptsetup is normally run with CAP_SYS_ADMIN, but not always (e.g.,
'cryptsetup benchmark').  It might be acceptable for users to add sudo
in the exceptional cases.  cryptsetup is being discussed in the thread
https://lore.kernel.org/linux-crypto/5dd3be22-13fb-41fb-b469-1ae6472200b1@gmail.com/

bluez needs investigation.

- Eric