[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260506043507.GA16204@sol>
Date: Tue, 5 May 2026 21:35:07 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: oss-security@...ts.openwall.com
Cc: Jan Schaumann <jschauma@...meister.org>
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
