Re: CVE-2026-31431: CopyFail: linux local privilege scalation

[Eric Biggers <ebiggers () kernel org>]

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/20260430011544.31823-1-ebiggers () kernel org/)
which marks it as deprecated.

I also sent a patch that removes AF_ALG's zero-copy support
(https://lore.kernel.org/linux-crypto/20260504225328.25356-1-ebiggers () kernel org/).
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