Re: [oss-security] CVE-2026-31431: CopyFail: linux local privilege scalation

[Eric Biggers <ebiggers@kernel.org>]

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