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

[Demi Marie Obenour <demiobenour () gmail com>]

On 5/1/26 16:18, Eric Biggers wrote:
> On Fri, May 01, 2026 at 03:24:51PM -0400, Demi Marie Obenour wrote:
> > On 5/1/26 14:00, Eric Biggers wrote:

(snip) 

> > > But people need to help.  Send patches to iwd, bluez, cryptsetup, etc.
> > > that make them use userspace crypto libraries instead of AF_ALG and
> > > KEYCTL_PKEY_*.  If the maintainers aren't convinced yet, then patch
> > > downstream in your distro as a starting point (and disable the UAPIs in
> > > your kernel).  Or help in other ways like writing blog posts that
> > > promote attack surface reduction and the alternatives to these UAPIs.
> > >
> > > I'd also like to explore some more incremental approaches, such as
> > > making these UAPIs require CAP_SYS_ADMIN, possibly configurable by a
> > > sysctl.  If anyone knows of anything important that would be broken by a
> > > CAP_SYS_ADMIN requirement on AF_ALG and KEYCTL_PKEY_*, let me know.
> >
> > Cryptsetup needs CAP_SYS_ADMIN, but iwd definitely does not, and
> > presumably BlueZ should not use have it either.
> >
> > Cryptsetup is a special case because there are times when it may not
> > be safe to allocate memory: if I/O to the swap partition is suspended,
> > and the kernel tries to page data out to it, the system may deadlock.
> > So calling into arbitrary third-party libraries might not be the best
> > idea.  Thankfully, Nettle should meet all of cryptsetup's requirements.
>
> Cryptsetup only uses AF_ALG for certain operations like keyslot
> encryption, and only in certain cases: Cryptsetup's default settings
> work fine with all CONFIG_CRYPTO_USER_API_* options disabled in the
> kernel.  The actual I/O to/from encrypted partitions is handled by
> dm-crypt in the kernel and has nothing to do with AF_ALG.
>
> Cryptsetup even already supports userspace crypto libraries as well.  It
> seems there are just some gaps in how it's using them.  For example for
> AES-GCM it seems to just go directly to AF_ALG, despite the cryptsetup
> binary already being linked to OpenSSL, which means a complete userspace
> implementation of AES-GCM is already present in its address space!

That's really annoying, yikes!

> > > I think there should also be an allowlist of algorithms, and the splice
> > > support should be removed.  (Interestingly, there's precedent for
> > > removing splice support from AF_ALG: it was already removed from the 6.1
> > > LTS kernel last year, seemingly accidentally.  That's why the copy.fail
> > > exploit didn't work on 6.1 but did work on other versions.)
> > >
> > > - Eric
> >
> > Would an allowlist and removing splice support allow migrating to
> > the crypto library code?  I looked at the list of CVEs you provided,
> > and I think it would prevent most of the recent ones.  The crypto
> > library is (as you pointed out) so much easier to use.
>
> I'm hoping that at least some of these ideas for attack surface
> reduction (requiring CAP_SYS_ADMIN, allowlisting the algorithms,
> removing splice support) can be implemented in parallel without waiting
> for every userspace program to stop using these UAPIs.  Full removal
> needs to be the goal, though.

CAP_SYS_ADMIN isn't going to be an option for iwd at least.
Requiring a Wi-Fi daemon to run as root would be counterproductive.
A more flexible option would be to require membership in a specific
group, which isn't equivalent to full root privileges.

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.

> > Also CCing the iwd mailing list.  iwd uses the kernel crypto APIs
> > wherever possible, which is a serious problem.  However, it already
> > needs to perform cryptography in userspace because of ECC.
> >
> > Nettle provides trivial no-allocation cryptographic APIs.  Nettle's
> > licensing (LGPLv3+ or GPLv2+) might prevent this, though.  OpenSSL has
> > a horrible API, but AWS-LC has a much better one.  It also implements
> > TLS, which would might allow iwd to get rid of its built-in TLS code
> > for EAP-TLS.
>
> It's unfortunate that the situation with userspace crypto libraries is
> fragmented, with the de facto standard one (OpenSSL) not being all that
> great.  But that's no excuse to say "put it all in the kernel".  Even
> using OpenSSL would still be much better.
>
> - Eric
I think there *might* be embedded systems that simply cannot use OpenSSL
because the memory (RAM and/or flash) needed for it simply is not there.
That said, I *do* wonder if one could somehow put cryptographic code in
the vDSO, or even have it share pages with the kernel.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature