Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Ignat Korchagin
Date: Mon May 11 2026 - 17:03:51 EST
On 10/05/2026 17:32, Eric Biggers wrote:
On Sun, May 10, 2026 at 08:54:07AM -0700, Kamran Khan wrote:
Hi,Note that if that memory-safety vulnerability leads to code execution in
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.
the application, then it doesn't matter that it "only" has oracle
access. It can still decrypt any data encrypted by that key.
I don't think fully discounting hardware offloading is beneficial here. HW accelerators will be produced and without a common interface vendors would start implementing their own "bespoke" drivers with bespoke userspace interfaces (we already had such proposals), which in turn may introduce more attack surface. Yes, AF_ALG needs substantial improvement, but at least it can be a standardisation point.
The relevant threat model would be arbitrary reads, not any
"memory-safety vulnerability".
I understand and appreciate the concern with complex attack surface and theThe standard solution is simply to use an isolated userspace process
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.
like ssh-agent. Yes, the keys will be in "user memory". But "not
exposed in user memory" is *not* a correct statement of the problem.
(Also note that protecting not-actively-in-use data from arbitrary read
primitives doesn't require cryptography at all. That can be done simply
by using mprotect() to remove read permission from the memory, then
temporarily adding it back when it needs to be accessed.)
In any case, any hypothetical security benefit provided by AF_ALG would
have to be *very high* to outweigh the continuous stream of
vulnerabilities in it. I understand that people using AF_ALG might not
be familiar with that continuous stream of vulnerabilities, but it would
Is it actually that much compared to other features/subsystems, like eBPF or user namespaces? But we don't rush to deprecate those - instead trying to harden them and come up with better design.
be worth spending some time researching what has been going on.
- Eric
Ignat