On Thu, Apr 30, 2026 at 12:19:17AM -0700, Eric Biggers wrote: > But I also hope this finally provides some more impetus for AF_ALG to be > deprecated and removed. It's a massive, largely pointless attack > surface which has been causing problems, including regular CVEs, ever > since it was added to the kernel in 2010. And of course it's gotten > even worse lately, with LLMs now being able to find the bugs. > > Userspace crypto libraries exist. There's no need to escalate to kernel > mode just to do some math. > > On Linux systems with no programs that use AF_ALG, it can already be > disabled in the kconfig by unsetting CONFIG_CRYPTO_USER_API_*. > > But there are some holdouts like iwd (iNet wireless daemon) that are > keeping general-purpose Linux distros from being able to disable it. > > It may also be time for a sysctl that allows restricting it to root, or > only to certain algorithms, etc. There is zero reason for "authencesn" > (which the exploit uses) to be accessible, for example.
For what it's worth, there's now a statement from the author of both algif_aead and commit 72548b093ee38a6d which introduced this bug: https://www.chronox.de/#comment-of-bug-cve-2026-31431 Sounds like even he doesn't think AF_ALG is a good idea anymore. The maintainer of AF_ALG has also accepted a patch (https://lore.kernel.org/linux-crypto/[email protected]/) which marks it as deprecated. I also sent a patch that removes AF_ALG's zero-copy support (https://lore.kernel.org/linux-crypto/[email protected]/). That would have prevented this vulnerability. An algorithm allowlist probably will come next. I determined the list of algorithms that iwd uses, for example (https://lore.kernel.org/linux-crypto/20260504045007.GA2289@sol/). Of course, as expected, it doesn't include "authencesn"... I think there are lessons here for other kernel UAPIs. Zero-copy support in particular is really dangerous, as by design it allows, for example, pagecache pages of the 'su' binary to be passed to a large body of kernel code that needs to be super careful not to write to it. While zero-copy support probably can't go away in performance-critical networking and file I/O code, there may be other rarely used or deprecated UAPIs from which it can be feasibly removed. Nor is it a good idea for UAPIs to "automatically" expose large amounts of functionality to userspace unnecessarily, especially things that could be done in userspace, like math computations. Hardly a new insight, of course; syzbot has always loved UAPIs like these. But it's worth repeating. UAPIs should be specific, minimal, do things only the kernel can do, *and* also be useful enough to be worth the price. - Eric
