[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260501201841.GA2540@quark>
Date: Fri, 1 May 2026 13:18:41 -0700
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 03:24:51PM -0400, Demi Marie Obenour wrote:
> On 5/1/26 14:00, Eric Biggers wrote:
> > On Fri, May 01, 2026 at 11:30:17AM -0400, Demi Marie Obenour 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.
> >>
> >> The only reason I can think of to keep it is for embedded systems
> >> with weak CPUs and crypto accelerators that are actually worth using.
> >> However, those seem to be very rare outside of things like routers,
> >> which run specialized distros like OpenWRT. Even when the accelerator
> >> exists and is worth using, AF_ALG is certainly not an efficient way
> >> to access it.
> >>
> >> Furthermore, an inline encryption engine in the NIC would be a much
> >> better choice for future router designs. AF_ALG doesn't work with
> >> that at all.
> >
> > All correct, of course.
> >
> > The main other claimed benefit of AF_ALG (and the similar KEYCTL_PKEY_*)
> > that sometimes gets mentioned is, ironically, a security one: keys can
> > be kept out of a particular userspace processes's address space.
> >
> > But:
> >
> > - Different userspace processes have different address spaces too. So
> > it already can be, and indeed often already is, done in userspace.
> >
> > - This security benefit is kind of besides the point when the interface
> > has a privilege escalation bug every few months.
> >
> > - The kernel often doesn't support the algorithm needed, or if it does,
> > some of them just aren't as well maintained as userspace libraries
> > like OpenSSL and BoringSSL. For example, the kernel's RSA
> > signing/decryption code is vulnerable to timing side-channels.
> >
> > (I'd like to specifically call out
> > https://blog.cloudflare.com/the-linux-kernel-key-retention-service-and-why-you-should-use-it-in-your-next-application/
> > as being misleading and harmful. It says to use the kernel for RSA
> > private key operations. But it fails to mention the kernel's RSA
> > implementation being vulnerable to timing side-channels or the steady
> > stream of vulnerabilities in the associated UAPIs.)
> >
> >>> 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.
> >>
> >> If AF_ALG was removed from the kernel, that would provide an incentive
> >> for someone to patch iwd to use a userspace library instead. Or if
> >> iwd is unmaintained, it (sadly) needs to be removed from distros.
> >> (Sadly because wpa-supplicant is much less well designed.)
> >
> > Where iwd is used, AF_ALG can't just be removed from the kernel
> > unilaterally. People would complain that iwd is broken and invoke the
> > "no regressions" rule. While only a few programs use it (iwd, bluez,
> > cryptsetup with certain options), they are enough for this to happen.
> >
> > We do remove algorithms from AF_ALG occasionally, but we've been unable
> > to remove ones like MD4 (yes, that MD4) that are still used by iwd:
> > https://lore.kernel.org/linux-crypto/946591db-36aa-23db-a5c4-808546eab762@gmail.com/
> > Likewise with removing support for SHA-1 from KEYCTL_PKEY_*
> > (https://lore.kernel.org/linux-crypto/f0492c92-1015-48e3-bfce-598c7a4843d1@quicinc.com/).
> > People even post the Linus quote "we simply do not break user space".
> >
> > Unfortunately, the developers and users of this small set of userspace
> > programs are disconnected from the extraordinary amount of time and
> > effort that the rest of the Linux community is putting in to maintain
> > these UAPIs and respond to the continuous stream of vulnerabilities.
> >
> > To them these are simply APIs available that work.
> >
> > This is actually one of the reasons I've been making these public posts:
> > this needs to be a community effort to deprecate these UAPIs.
> >
> > If the developers of these userspace programs aren't taking action yet,
> > people need to volunteer to go in and fix these programs. Again, it's
> > actually a pretty small set of programs that even uses this stuff.
> >
> > This would be really impactful to the security of Linux.
> >
> > A lot of the discourse around this vulnerability has focused on the
> > things that went wrong with the patching. It did go very badly, but I
> > feel it's also missing the point a bit. AF_ALG and KEYCTL_PKEY_*
> > actually have a continuous stream of vulnerabilities, which has only
> > accelerated in the era of LLMs. Just in the last year there have been
> > at least 4 privilege escalations in AF_ALG, I think. We need to fix the
> > root cause of why this is happening.
> >
> > And I think it really can be fixed. It's just a few programs that are
> > using these UAPIs. Many systems already don't need them at all.
> >
> > 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!
> > 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.
> 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
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.
