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

[Eric Biggers <ebiggers@kernel.org>]

On Mon, May 11, 2026 at 10:03:21PM +0100, Ignat Korchagin wrote:
> 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.

That isn't the best way to accelerate symmetric crypto anymore though,
if it ever was.  This has been known for a long time.

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

There are plenty of other kernel features with a large attack surface,
of course.  But they tend to be much more useful than AF_ALG.  It's all
about weighing benefits vs. risks.

When we get the point where a large number of Linux users *had* to
disable AF_ALG as an emergency vulnerability response, and at the same
time their systems weren't even using AF_ALG so nothing even broke and
they could have just done that to begin with, I think we get a very
clear idea of which side is heavier for AF_ALG in the real world.

The main relevance of AF_ALG to the Linux community is that it allows
their systems to be exploited.

- Eric