Hi,

AF_ALG is useful not just for hardware-offloading, but also for memory 
isolation so that applications only get oracle access to the crypto keys 
and a memory-safety vulnerability in user applications would not 
immediately put the secret key material at risk.

I understand and appreciate the concern with complex attack surface and 
the increased frequency of attacks in this area. But I fear that 
completely removing AF_ALG increases the risk for userspace applications 
relying on it for memory isolation.

What alternatives do userspace applications have on Linux for ensuring 
crypto keys are not exposed in user memory? That is, FreeBSD and NetBSD 
natively provide /dev/crypto; removing AF_ALG would kill the only 
equivalent option on the Linux side for kernel-delegated cryptography.

Thanks,
Kamran.

On 5/6/26 7:42 AM, Jeff Barnes wrote:

Hi,

On May 5 2026, at 7:17 pm, Andy Lutomirski [off-list ref] wrote:

quoted

quoted

On Apr 29, 2026, at 6:19 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/

  
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.

Apologize in advance for the long-winded answer.

The "FIPS stuff" centers on using sha512hmac -> libkcapi -> AF_ALG for
verifying integrity. The early‑boot sha512hmac check that some
distributions use (typically from initramfs) sits at an awkward
intersection of multiple standards, and it may help to clarify where it
actually fits and where it doesn't.

 From a standards perspective, FIPS 140‑3 requires a cryptographic module
to perform self‑integrity verification using an approved algorithm and
to prevent the module from entering an operational state on failure. In
the Linux kernel, the cryptographic module is the kernel crypto
subsystem, and these requirements are met by the kernel’s internal
power‑up self‑tests (KATs, etc.) on the crypto code and critical data as
loaded into memory.

FIPS 199 / SP 800‑53 (e.g., SI‑7) impose system‑level integrity
requirements (for Moderate impact systems), i.e., that unauthorized
modification of critical components is prevented or detected and that
failures result in a protective action. These controls are explicitly
technology‑agnostic and are not limited to cryptographic‑module self‑tests.

The sha512hmac check is not the FIPS 140‑3 cryptographic‑module
self‑integrity test. Instead, it has historically been used as a system
integrity control that provides auditors with assurance that the kernel
image containing the cryptographic module has not been modified prior to
execution, and that a failure will halt the boot.

Although FIPS 140‑3 does not mandate an HMAC over the kernel image, the
early‑boot HMAC became an accepted evidence pattern for satisfying
system‑integrity expectations (FIPS 199 / SI‑7) alongside a kernel
crypto validation. This is why it is often perceived as “required” for
FIPS submissions, even though it is not normatively required by
FIPS 140‑3 itself.

With the deprecation/removal of AF_ALG for this use case, there is no
longer a supported way to perform an early‑boot, userspace‑driven HMAC
using validated kernel crypto without introducing circular dependencies
(e.g., relying on userspace crypto before crypto self‑tests complete).
As a result, there is no drop‑in replacement for sha512hmac that
preserves all of its historical properties.

This is a new development that challenges a long‑standing assumption:
that system‑integrity evidence and cryptographic‑module self‑integrity
can be cleanly separated while still being demonstrated by a single
early‑boot mechanism. That assumption no longer holds given proposed
kernel interfaces.

A more accurate decomposition (and one that aligns with the intent of
the standards) is to separate integrity enforcement by system phase.

1. Secure Boot (or equivalent platform verification) ensures that a
modified kernel image is not executed at all. This satisfies the
requirement that critical components are not loaded in a modified state
and that integrity failure results in a protective action (boot prevention).

2. IMA (with appraisal and enforcement) ensures that modified
executables, modules, or firmware cannot be loaded or executed once the
kernel is running.

3. Kernel crypto self‑tests continue to satisfy FIPS 140‑3
self‑integrity requirements independently of the above.

Taken together, Secure Boot + IMA provide continuous system‑integrity
enforcement without re‑introducing early‑boot HMACs or AF_ALG
dependencies, while keeping cryptographic‑module self‑integrity
correctly scoped to the kernel crypto subsystem.

The transition away from sha512hmac is therefore not a removal of
integrity enforcement, but a shift from a single, early‑boot mechanism
to a phased integrity model that better reflects the separation of
concerns already present in the standards — even though this separation
was previously masked by the hacky HMAC approach.

This change will require updated documentation and auditor education,
but it reflects the current technical reality and avoids perpetuating an
interface that no longer has a sustainable implementation path.

quoted

quoted

  
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