[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260502033556.GA3872267@google.com>
Date: Sat, 2 May 2026 03:35:56 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Demi Marie Obenour <demiobenour@...il.com>
Cc: oss-security@...ts.openwall.com,
Jan Schaumann <jschauma@...meister.org>, iwd@...ts.linux.dev
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
On Fri, May 01, 2026 at 08:21:27PM -0400, Demi Marie Obenour wrote:
> I think the single biggest hardening win for AF_ALG would be to move
> to the crypto library. The recent CVEs you mentioned mostly seem
> to relate to the crypto API, and with a hard-coded list of allowed
> algorithms there's no need to use the crypto API anymore. I'm not
> familiar enough with kernel code to do this easily, but for anyone
> with basic knowledge of the existing code it should (hopefully) be
> straightforward.
>
> In the meantime, only using synchronous algorithms and not using
> hardware drivers would also be a useful simplification. The latter
> would make it especially clear that AF_ALG is deprecated, because
> its one potential advantage (being able to use hardware acceleration)
> would no longer be present.
The kernel's crypto library
(https://docs.kernel.org/crypto/libcrypto.html) does greatly simplify a
lot of kernel code that needs to use crypto algorithms. Yes, AF_ALG
doesn't use it directly yet. Currently AF_ALG puts all the data in
(zero-copy) scatterlists, then invokes the "traditional crypto API"
which is very complex and has full scatterlist support, asynchronous
execution support, an algorithm template system, etc. In some cases the
crypto library is then used internally, but it's not called directly.
So the idea would be something along the lines of:
- Add an algorithm allowlist to AF_ALG. It would include only what the
small set of userspace programs that uses it actually needs. Bizarre
stuff like "authencesn" wouldn't be included.
- Change AF_ALG to make it copy any data written to an AF_ALG file
descriptor into an internal kernel buffer. Put the output in another
internal kernel buffer, then copy it to userspace. No zero-copy, and
no scatterlists. Both restrictions would greatly reduce the chance of
bugs: the actual crypto algorithms would operate only on these
internal buffers, not on pagecache data (e.g. the contents of 'su') or
buffers that userspace can concurrently modify. The use of simple
virtual addresses would eliminate all the scatterlist complexity.
- AF_ALG would implement each algorithm by invoking the corresponding
the crypto library functions
(https://docs.kernel.org/crypto/libcrypto.html#api-documentation). No
asynchronous execution, no buggy hardware crypto drivers, etc.
It sounds good to me. For people who feel like the su binary on their
system is a bit too restrictive and would like to fix that, these
changes might not be all that great for them. But for the rest of us,
they should work rather well.
Of course, it'll also be a fair a bit of work, and unfortunately I also
expect pushback from people who (incorrectly IMO) think that AF_ALG
performance is important, even moreso than security.
Either way, the first step will be to create the algorithm allowlist,
which should happen anyway, regardless of the other changes.
(By the way, for context: I maintain the kernel's crypto library, but
not the kernel's "traditional crypto API". The latter is where AF_ALG
and all these problems are, unfortunately.)
- 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.
