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

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

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 7540 bytes --]

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.

> 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.

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eric Biggers]

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

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

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 5271 bytes --]

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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eric Biggers]

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

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

[Eric Biggers]

On Sat, May 02, 2026 at 03:35:58AM +0000, Eric Biggers wrote:
> So the idea would be something along the lines of:

And just to make sure no one gets the wrong impression: just because
there seem to be ways in which the attack surface of AF_ALG could/should
be reduced doesn't mean that userspace should keep using it (or even
worse, start to use it).  Fixing programs like iwd needs to proceed
concurrently, so that eventually (some years down the line) the problem
can finally be fully solved by removing AF_ALG from the kernel source.

- Eric

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

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1012 bytes --]

On 5/1/26 23:54, Eric Biggers wrote:
> On Sat, May 02, 2026 at 03:35:58AM +0000, Eric Biggers wrote:
>> So the idea would be something along the lines of:
> 
> And just to make sure no one gets the wrong impression: just because
> there seem to be ways in which the attack surface of AF_ALG could/should
> be reduced doesn't mean that userspace should keep using it (or even
> worse, start to use it).  Fixing programs like iwd needs to proceed
> concurrently, so that eventually (some years down the line) the problem
> can finally be fully solved by removing AF_ALG from the kernel source.
> 
> - Eric

Can AF_ALG be emulated using LD_PRELOAD?  That would allow it to be
eliminated from the kernel much more quickly, as one would not need
to get rid of all of its existing users.  It would even work for those
who need AF_ALG because of closed source binaries, who otherwise will
have no alternative other than running an old kernel in a VM.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Greg Dahlman]

Note: re-adding the other lists so that people have an opportunity to
correct my errors.

"CAP_FOO in the init namespace" doesn't matter if "CAP_FOO" is the
gate in the default namespace, namespaces a facade-pattern and not an
isolation, unix abstract sockets, af_inet, vsock, af_alg etc... do not
currently use credentials at all IIRC.


LD_PRELOAD, as a way to (transparently) replace this functionality
without user intervention , involves putting in an interposer to
directly intercept all socket() calls at a system scale in this case,
when it is typically a thread scope concept.

I think socket() hasn't been interposable for at least a decade (in
glibc) you will weaken overall security by reintroducing the PLT or...
Note many people want to avoid adding in a `/etc/ld.so.preload`
because fighting dynamic linker hijacking is not easy due to Unix-like
systems having zero security boundary between the parent and child
process.

The bigger problem is that the embedded users are not where most of
the friction is going to come from, while the motivations are similar,
FIPS 140-3 validation, and downstream vendors which used distros
validations, incorporated into regilitory, compliance, and governance
is a large unidentified user base.

Searching for "Kernel Crypto API" in the Module name on this site will
show some of the upstream validations.

   https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search


In the case of non path backed sockets, userns provides zero
protections and only adds to the attack surface, the only credential
use for non-path backed sockets currently is the restriction of ports
below 1024 on af_inet,

Remember namespace support is not implicit, and all af_family calls
outside of those specific families that have namespace support all
stay in the default namespace.

If you dig through the $distro openssl security documents from the
NIST link above from the vendors you will see why people liked the
contract that af_alg offered, because they were depending on the
kernel teams stable api and reputation. and they could simplify their
compliance because it is easier to ensure no openssl installs exist at
all on a system than to try and maintain compliance, governance, and
regulatory obligations.

While there are some use cases like firmware images on some embedded
systems, where having the DMA pipe into a cryptoengine avoided Von
Neumann bottleneck issues and CPU usage etc.. No matter how flawed it
is to use af_alg, it provided a simple zero dependency interface that
their tools already supported (socket) and reduced their lifecycle
costs.  The reduced performance of the hw crypto engines for smaller
data sizes was acceptable as a trade-off, not as the primary driver in
many cases.

I should be 100% clear, namespaces _are not_ a security feature, but
they can be leveraged to lower privileges and improve a security
posture.  But when you have interfaces like sockets (non unix like)
the main advantage of network namespaces is they allow you to
constrain something that due to historical reasons has almost zero
controls (except tcp ports < 1024).

But the default is for any new, legacy or other subsystem to only live
in the default namespace.  The friction is when ~4 out of the 40+
af_families is namespace but the rest are not.

There is a very real problem with people overestimating the isolation
capabilities of namespaces in general, but paying attention to the
official documentation may help here:

https://www.kernel.org/doc/html/latest/admin-guide/namespaces/compatibility-list.html

     The same is true for the IPC namespaces being shared - two users
from different user namespaces should not access the same IPC objects
even having equal UIDs.
     But currently this is not so.

The "should not access" is a very different contract than most people expect.

The FIPS/ISO compliance issue mostly invalidates what I hoped was an
easy fix and putting a kernel call interposer via ld_preload will
still add  friction that is likely to block the aspirations of
removing af_alg from the kernel.  I think that there is a path to do
so, and I think it would be best in the long run.  But the friction
here is not just from code changes, which are far easier to accomplish
than the regulatory issues.

The compliance based user base is one that is often far more challenging.

I do still think that both userland and kernel would benefit from some
mechanism that would make it easier for security teams, admins, and
users to run with lower privileges.  IMHO thinking about enabling that
control will also be critical to the kernel team's ability to remain
effective.  Different use cases will always conflict, and
non-namespace users would also benefit from ways to restrict access to
af_families.

IMHO if the team thinks af_alg is unfixable, it is maybe one of the
rare cases where breaking changes are necessary.  It may be more
productive to help compliance based users migrate than provide a
brittle shim that still invalidates all their authorizations anyway.

I am not an expert on FIPS/ISO compliance, but I do know that
providing guidance that helps users migrate would go a long way.  You
could say, have a userland process that provides a socket-like
interface with guidance on how to wrap or create a their_socket() to
migrate.

I still think that for non af_inet/unix (file backed)socket af
families, there needs to be a credentials mechanism.  People are
building systems on top of vsock and other non unix/if based systems
that are just as vulnerable. Like af_alg, vsock is known to have
serious issues and was designed for a trusted environment.  Without an
effective way to limit exposure from either userland or the kernel
there is enough that is simply just unexplored that it will be
expensive.

On Sun, May 3, 2026 at 5:00 AM Simon McVittie <smcv@debian.org> wrote:
>
> On Sat, 02 May 2026 at 14:21:57 -0600, Greg Dahlman wrote:
> >LD_PRELOAD and capabilities
>
> These seem orthogonal, rather than being part of the same idea.
>
> LD_PRELOAD is discretionary (cooperative) so it would only be useful if
> used in a design something like this:
>
> - at the kernel level, AF_ALG just doesn't work (fails with a
>    permission-related error), at least for unprivileged processes
> - but in user-space, an opt-in LD_PRELOAD module intercepts the socket(),
>    etc. calls for AF_ALG, and emulates the behaviour of current kernels
>    by calling into a user-space crypto library
>
> It can't be a security boundary, but it can be a mitigation for the
> regressions that a new security boundary (or complete feature removal)
> would otherwise cause, similar to the way LD_PRELOADs like aoss and
> padsp mitigated the regressions for older binaries when distro kernels
> disabled OSS audio.
>
> Meanwhile capabilities are a way to let trusted, privileged processes
> have access to things that unprivileged processes do not, for example
> making AF_ALG available to a few system services that need it but not
> available to all of user-space.
>
> >You should expect any UID (even nobody) to be able to gain the
> >privileges in their bounding set
>
> The kernel can distinguish between "CAP_FOO in the init namespace" and
> "CAP_FOO in any other userns" if it wants to, and some kernel features
> are already gated by having a capability in the init namespace
> specifically. For example CAP_SYS_ADMIN in the init namespace allows
> mounting block-device-backed filesystems like ext4, but CAP_SYS_ADMIN in
> a different userns only allows a few "safe" mount operations
> (bind-mounts, overlayfs, FUSE).
>
>      smcv

AF_ALG hardening

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 5269 bytes --]

On 5/1/26 23:35, Eric Biggers wrote:
> 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.

Yup!  That's exactly the idea.

> 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.

If one cares about crypto offload performance, they would be better
served by creating a better interface to it than AF_ALG.  AF_ALG is
a horrible API with (presumably) tons of overhead.  I know the QAT
driver and an Nvidia BlueField DPU accelerator driver both bypass it.

Furthermore, AF_ALG only supports symmetric algorithms.  These
algorithms are inexpensive in software, so the cost of going to an
accelerator and back is enormous compared to the cost of a single
operation.  For offload to even a very fast accelerator to make sense,
one must be able to deeply pipeline requests.  However, this creates
a huge amount of additional complexity for software.

On the other hand, asymmetric cryptography performs far more work per
operation.  This might (no benchmarks!) mean that offloading asymmetric
algorithms makes more sense than offloading symmetric ones.  The cost
of sending the work to the accelerator and waiting for completion
is less than the time needed to perform the operation, so even a
synchronous interface could still be faster than running the algorithm
on the CPU.  Furthermore, long-term keys are very often asymmetric,
so DPA and EMA protections are much more likely to be relevant here.
Asymmetric accelerators also don't have a better alternative in the
form of inline encryption hardware.

I think a high performance interface to hardware cryptography (and,
more importantly, compression) would look much more like RDMA.
There would be a kernel driver that did the bare minimum to provide
isolation between userspace programs, and a userspace driver that
was responsible for abstracting over the hardware.

> Either way, the first step will be to create the algorithm allowlist,
> which should happen anyway, regardless of the other changes.

The simplest changes I can see are:

1. Get rid of zero-copy support (splice()).
2. Get rid of AIO support.
3. Only allow software implementations.

All of these are really simple.  I can send patches, but be warned
that they would only be compile-tested, as I don't know how to test
the code.

I removed oss-security from CC as this is now a Linux kernel development
discussion.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: AF_ALG hardening

[Simon Richter]

[-- Attachment #1.1: Type: text/plain, Size: 4788 bytes --]

Hi,

On 5/2/26 13:52, Demi Marie Obenour wrote:

>> 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.

AF_ALG performance (time/power) is important in the way that it's 
literally the only point to its existence. If all it provides is extra 
overhead over a software implementation, then it makes no sense to keep it.

> If one cares about crypto offload performance, they would be better
> served by creating a better interface to it than AF_ALG.  AF_ALG is
> a horrible API with (presumably) tons of overhead.  I know the QAT
> driver and an Nvidia BlueField DPU accelerator driver both bypass it.

The API is designed to be zerocopy, that's why it's this horrible 
combination of socket API and splice(). The general assumption here is 
that it does not make sense to offload small requests in the first 
place, and application programmers are aware of that.

The use case is "I have a file or pipe full of data and a device with a 
kernel driver that should process it, can we somehow avoid copying the 
data to userspace only to immediately copy it back to kernelspace?"

This copying is even more silly if the actual question I have in 
userspace is "what is the SHA256 checksum of this file?" or "what is the 
SHA256 checksum of the string 'blob 8794311528\0' followed by this 
file?" (where you can see why anyone would ask such a silly question and 
prefer to use the dedicated hardware that processes 24 GB/s over the CPU 
at 100 MB/s)

> Furthermore, AF_ALG only supports symmetric algorithms.  These
> algorithms are inexpensive in software, so the cost of going to an
> accelerator and back is enormous compared to the cost of a single
> operation.

Yes, initial setup cost is high, so this only makes sense for large 
requests or batches (submitting individual requests is generally cheap, 
the difficulty is ensuring the data is accessible to the hardware).

That's also why there are no asymmetric algorithms: these aren't 
generally used on large amounts of data, so it's never worth it to 
offload these.

It would make sense to offload asymmetric algorithms if there was a 
secure key storage inside the device, but AFAIK the API does not support 
that, or even the notion of on-device contexts.

It is not a good API, and it sits on top of the ahash/acomp/acrypt 
interfaces which are also unfriendly to accelerator hardware.

> For offload to even a very fast accelerator to make sense,
> one must be able to deeply pipeline requests.  However, this creates
> a huge amount of additional complexity for software.

Software that has requirements like that is already complex -- if I have 
a few thousand workload packets, I need a worker pool.

If I don't have these requirements, then indeed I am better off with a 
software-only solution in userspace, because it is not relevant from a 
performance standpoint.

> Asymmetric accelerators also don't have a better alternative in the
> form of inline encryption hardware.

Quite a number of architectures do not have inline encryption support, 
and these are more likely to use offload hardware even for smaller 
requests (e.g. for power saving).

> I think a high performance interface to hardware cryptography (and,
> more importantly, compression) would look much more like RDMA.
> There would be a kernel driver that did the bare minimum to provide
> isolation between userspace programs, and a userspace driver that
> was responsible for abstracting over the hardware.

Offload hardware comes in two flavours: the high-throughput kind, built 
into devices where no one cares about power, and the 
lower-power-than-the-CPU-doing-it kind.

The former can easily provide user contexts even in virtualized 
environments, but the latter is generally found in systems that do not 
even have an IOMMU. Either we have two distinct interfaces for these, or 
we need one that can handle either.

My feeling is that no one is happy with either AF_ALG or the 
asynchronous interfaces in general, so I think they should be removed 
completely, and there should be a separate "offload" SIG that creates 
new interfaces that are actually usable with current hardware.

 > 1. Get rid of zero-copy support (splice()).
 > 2. Get rid of AIO support.
 > 3. Only allow software implementations.

That makes sense if we're forced to keep the interface for now, but it 
means that offload support through the crypto subsystem is completely 
dead, and anyone wanting to support offload hardware needs to go 
elsewhere. Can we get a definitive statement that this is intended?

    Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: AF_ALG hardening

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 7336 bytes --]

On 5/2/26 04:19, Simon Richter wrote:
> Hi,
> 
> On 5/2/26 13:52, Demi Marie Obenour wrote:
> 
>>> 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.
> 
> AF_ALG performance (time/power) is important in the way that it's 
> literally the only point to its existence. If all it provides is extra 
> overhead over a software implementation, then it makes no sense to keep it.

The only reason for keeping it is for compatibility with existing
userspace.

>> If one cares about crypto offload performance, they would be better
>> served by creating a better interface to it than AF_ALG.  AF_ALG is
>> a horrible API with (presumably) tons of overhead.  I know the QAT
>> driver and an Nvidia BlueField DPU accelerator driver both bypass it.
> 
> The API is designed to be zerocopy, that's why it's this horrible 
> combination of socket API and splice(). The general assumption here is 
> that it does not make sense to offload small requests in the first 
> place, and application programmers are aware of that.
> 
> The use case is "I have a file or pipe full of data and a device with a 
> kernel driver that should process it, can we somehow avoid copying the 
> data to userspace only to immediately copy it back to kernelspace?"
> 
> This copying is even more silly if the actual question I have in 
> userspace is "what is the SHA256 checksum of this file?" or "what is the 
> SHA256 checksum of the string 'blob 8794311528\0' followed by this 
> file?" (where you can see why anyone would ask such a silly question and 
> prefer to use the dedicated hardware that processes 24 GB/s over the CPU 
> at 100 MB/s)

Do you have a specific device that has such hardware and can use an
upstream kernel?  I have yet to see any concrete examples.

>> Furthermore, AF_ALG only supports symmetric algorithms.  These
>> algorithms are inexpensive in software, so the cost of going to an
>> accelerator and back is enormous compared to the cost of a single
>> operation.
> 
> Yes, initial setup cost is high, so this only makes sense for large 
> requests or batches (submitting individual requests is generally cheap, 
> the difficulty is ensuring the data is accessible to the hardware).
> 
> That's also why there are no asymmetric algorithms: these aren't 
> generally used on large amounts of data, so it's never worth it to 
> offload these.

Asymmetric cryptography is far more expensive than symmetric
cryptography.  Tens of microseconds or more on a high-end CPU
I believe.

That is more than enough time to justify going to an accelerator and
back, if the accelerator can do the job significantly faster.

> It would make sense to offload asymmetric algorithms if there was a 
> secure key storage inside the device, but AFAIK the API does not support 
> that, or even the notion of on-device contexts.
> 
> It is not a good API, and it sits on top of the ahash/acomp/acrypt 
> interfaces which are also unfriendly to accelerator hardware.

Not surprised.

>> For offload to even a very fast accelerator to make sense,
>> one must be able to deeply pipeline requests.  However, this creates
>> a huge amount of additional complexity for software.
> 
> Software that has requirements like that is already complex -- if I have 
> a few thousand workload packets, I need a worker pool.

Or a thread-per-core architecture.

> If I don't have these requirements, then indeed I am better off with a 
> software-only solution in userspace, because it is not relevant from a 
> performance standpoint.
> 
>> Asymmetric accelerators also don't have a better alternative in the
>> form of inline encryption hardware.
> 
> Quite a number of architectures do not have inline encryption support, 
> and these are more likely to use offload hardware even for smaller 
> requests (e.g. for power saving).

Please provide a real-world example where that using the accelerator
really does save power compared to running the cryptography on the CPU.

>> I think a high performance interface to hardware cryptography (and,
>> more importantly, compression) would look much more like RDMA.
>> There would be a kernel driver that did the bare minimum to provide
>> isolation between userspace programs, and a userspace driver that
>> was responsible for abstracting over the hardware.
> 
> Offload hardware comes in two flavours: the high-throughput kind, built 
> into devices where no one cares about power, and the 
> lower-power-than-the-CPU-doing-it kind.

Again, please provide benchmarks.  I have yet to see a real-world
example where the accelerator is faster for short (read: realistic)
message sizes.  Eric Biggers has provided many where it is far slower,
and didn't find any situation where it saved power.

For very long messages, yes, it can be faster.  But I have yet to
see a situation where (a) performance for large files matters and (b)
there is an accelerator worth using.

Network and storage encryption is obviously performance-critical,
but it uses small messages.  Furthermore, both of them are well-suited
to inline cryptographic engines, which are much more efficient.

I mostly associate large file encryption and hashing with things
like verifying software updates.  On large systems, this matters
because a human is waiting.  However, these systems are also ones
for which software cryptography is very fast.  On small systems,
I expect update validation to be much less performance-critical.

> The former can easily provide user contexts even in virtualized 
> environments, but the latter is generally found in systems that do not 
> even have an IOMMU. Either we have two distinct interfaces for these, or 
> we need one that can handle either.
> 
> My feeling is that no one is happy with either AF_ALG or the 
> asynchronous interfaces in general, so I think they should be removed 
> completely, and there should be a separate "offload" SIG that creates 
> new interfaces that are actually usable with current hardware.
> 
>  > 1. Get rid of zero-copy support (splice()).
>  > 2. Get rid of AIO support.
>  > 3. Only allow software implementations.
> 
> That makes sense if we're forced to keep the interface for now, but it 
> means that offload support through the crypto subsystem is completely 
> dead, and anyone wanting to support offload hardware needs to go 
> elsewhere. Can we get a definitive statement that this is intended?

AF_ALG is dead.  Much of the rest of the kernel is moving from the
crypto API to the software-only crypto library.

Offload is far more complex than software cryptography, so there needs
to be a substantial benefit to justify using it.  Have you seen any
real-world cases of this?  Inline encryption hardware (both in storage
controllers and in NICs) is definitely a win, but it doesn't use the
crypto API at all.

It's easy to provide synthetic benchmarks where offload is a win, but
synthetic benchmarks don't justify a giant CVE magnet.  If offload is a
win in the real world, then it should be possible to demonstrate this.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: AF_ALG hardening

[Eric Biggers]

On Sat, May 02, 2026 at 12:52:57AM -0400, Demi Marie Obenour wrote:
> > Either way, the first step will be to create the algorithm allowlist,
> > which should happen anyway, regardless of the other changes.
> 
> The simplest changes I can see are:
> 
> 1. Get rid of zero-copy support (splice()).
> 2. Get rid of AIO support.
> 3. Only allow software implementations.
> 
> All of these are really simple.  I can send patches, but be warned
> that they would only be compile-tested, as I don't know how to test
> the code.

If you're interested, please send patches, and we'll see where things go
from there.  We need to get more people helping with this stuff.

For (1), it probably should work like the way the zero-copy support was
disabled in the 6.1 LTS kernel last year, where (I think) the splice()
syscall still succeeds but it just copies the data.

For (2) and (3), you can find examples of disabling asynchronous crypto
API stuff at
https://lore.kernel.org/linux-fscrypt/20250704070322.20692-1-ebiggers@kernel.org/
and
https://lore.kernel.org/linux-fscrypt/20250708181313.66961-1-ebiggers@kernel.org/.
Note that to request a synchronous algorithm you have to pass
CRYPTO_ALG_ASYNC (yes, really).

I think there are a few test scripts for AF_ALG in libkcapi.  Besides
that AF_ALG is barely tested.  So you're in good company.

- Eric

Re: AF_ALG hardening

[Simon Richter]

[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]

Hi,

On 5/3/26 04:16, Eric Biggers wrote:

> On Sat, May 02, 2026 at 12:52:57AM -0400, Demi Marie Obenour wrote:

>> The simplest changes I can see are:

>> 1. Get rid of zero-copy support (splice()).
>> 2. Get rid of AIO support.
>> 3. Only allow software implementations.

> For (2) and (3), you can find examples of disabling asynchronous crypto

I think we need to make up our minds here.

This thread is about removing asynchronous implementations and 
accelerator support from AF_ALG, so it can support legacy applications 
with known-good implementations, while the other thread[1] is about 
removing everything *but* accelerator support from AF_ALG -- and as 
accelerators are typically asynchronous, this aspect has to stay as well.

At least with the opposite proposals, it would be good to know which one 
is official policy.

At the same time, the third thread[2] deprecates AF_ALG because of its 
wonky security posture, while newer accelerators are implementing their 
own userspace interfaces because AF_ALG is too limited, so we're already 
replacing one CVE magnet with several independent ones, and deprecating 
AF_ALG means that future drivers will add even more of those because 
there is no longer a common framework to attach to.

Also, if AF_ALG is deprecated and the kernel no longer uses 
ahash/acrypt/acomp internally, there is no point in accelerator cards 
even registering with the crypto subsystem. Should that be an explicit 
policy "accelerator cards are outside the scope of the crypto subsystem, 
even if they implement a cryptographic algorithm"?

    Simon

[1] 
https://lore.kernel.org/linux-crypto/112bf0af-1551-4d3e-ab15-e5dea3fc2435@app.fastmail.com/

[2] 
https://lore.kernel.org/linux-crypto/20260430011544.31823-1-ebiggers@kernel.org/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: AF_ALG hardening

[Eric Biggers]

On Tue, May 05, 2026 at 04:01:47AM +0900, Simon Richter wrote:
> Hi,
> 
> On 5/3/26 04:16, Eric Biggers wrote:
> 
> > On Sat, May 02, 2026 at 12:52:57AM -0400, Demi Marie Obenour wrote:
> 
> > > The simplest changes I can see are:
> 
> > > 1. Get rid of zero-copy support (splice()).
> > > 2. Get rid of AIO support.
> > > 3. Only allow software implementations.
> 
> > For (2) and (3), you can find examples of disabling asynchronous crypto
> 
> I think we need to make up our minds here.
> 
> This thread is about removing asynchronous implementations and accelerator
> support from AF_ALG, so it can support legacy applications with known-good
> implementations, while the other thread[1] is about removing everything
> *but* accelerator support from AF_ALG -- and as accelerators are typically
> asynchronous, this aspect has to stay as well.
> 

Thread [1] is a patch that removes the kernel's last
architecture-optimized implementation of MD5, which is a broken and
deprecated algorithm anyway.  So it's not just AF_ALG that's motivating
that particular patch, but also a desire to focus effort on modern
algorithms and keep the different Linux architectures consistent.  So I
think the scope of that thread is more narrow than what you're claiming.

Also, it's already been established that for now AF_ALG will have to
keep the software code used by a small set of userspace programs such as
iwd.  So no, it cannot be completely removed yet (except on systems that
don't use any of these programs, where it can be already).  However,
that doesn't mean that we shouldn't be nudging people towards better
solutions, with an eye towards future attack surface reductions.

> At least with the opposite proposals, it would be good to know which one is
> official policy.
> 
> At the same time, the third thread[2] deprecates AF_ALG because of its wonky
> security posture, while newer accelerators are implementing their own
> userspace interfaces because AF_ALG is too limited, so we're already
> replacing one CVE magnet with several independent ones, and deprecating
> AF_ALG means that future drivers will add even more of those because there
> is no longer a common framework to attach to.

It's long been clear that by far the best way to accelerate symmetric
crypto is to just put it in the CPU, or in-line in the storage or
network controller.  Indeed, that's what almost everyone does now.

So I would expect the demand for this kind of interface to symmetric
crypto to continue to decline, as it already has been for a long time.
And as you pointed out, AF_ALG doesn't work well for it anyway, which
makes AF_ALG increasingly kind of besides the point.

> Also, if AF_ALG is deprecated and the kernel no longer uses
> ahash/acrypt/acomp internally, there is no point in accelerator cards even
> registering with the crypto subsystem. Should that be an explicit policy
> "accelerator cards are outside the scope of the crypto subsystem, even if
> they implement a cryptographic algorithm"?

There are still some in-kernel users of the asynchronous crypto APIs,
for example IPsec and dm-crypt.  So I think your prediction of the
demise of these APIs is a bit premature as well.  But yes, at least for
the symmetric crypto, kernel subsystems have been been repeatedly seeing
that the async support just isn't worth it.  We'll see more kernel
subsystems switching to sync-only.  But in practice this is a gradual
transition.

Anyway, I don't think I'm proposing conflicting things.  We can and
should document a general deprecation of AF_ALG, while also helping
update userspace programs to no longer use it, while also applying
various hardening measures to reduce AF_ALG's attack surface as best we
can in the meantime.  There are multiple independent hardening measures
that could be applied, and they will be up for discussion on the
individual patches that implement them.

- Eric

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

[Milan Broz]

Hi,

On 5/1/26 9:24 PM, Demi Marie Obenour wrote:
> Cryptsetup needs CAP_SYS_ADMIN, but iwd definitely does not, and
> presumably BlueZ should not use have it either.

In cryptsetup, AF_ALG is used exactly in places where it does
NOT need CAP_SYS_ADMIN.

While I agree that AF_ALG is misdesigned (specifically, indirect
loading of kernel modules just on non-privileged user request),
it is used in real scenarios.

I can write a long story why it is used in cryptsetup, but long
story short:

- It is used for benchmarking, where we actually need kernel crypto.

As it will be used in real dm-crypt mapping later, benchmarking
userspace lib just does not make sense.
(Requiring CAP_SYS_ADMIN here is not such a big issue, and it is
a very rough test - but useful for relative comparison, not for the
real numbers.)

- It is used in TrueCrypt/VeraCrypt compatibility (at least).

This format needs to decrypt the header (first sector) with
the same algorithms as it is later mapped through dm-crypt.
Not everything is available in userspace (we support all historic
versions) and using AF_ALG was very convenient here.

By removing AF_ALG, you will completely break this format support.
including some distros (I think Tails uses that :).

We are using userspace libraries, but removing AF_ALG would be a pain.
It can be done, but it requires time.

> 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.

The cause with the swap is not such a big deal in reality.

Nettle is NO WAY for cryptsetup (we have support for it as an alternative
backend, but it cannot be the default). You do not see the whole picture.

Thanks,
Milan

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

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 2514 bytes --]

On 5/4/26 01:57, Milan Broz wrote:
> Hi,
> 
> On 5/1/26 9:24 PM, Demi Marie Obenour wrote:
>> Cryptsetup needs CAP_SYS_ADMIN, but iwd definitely does not, and
>> presumably BlueZ should not use have it either.
> 
> In cryptsetup, AF_ALG is used exactly in places where it does
> NOT need CAP_SYS_ADMIN.
> 
> While I agree that AF_ALG is misdesigned (specifically, indirect
> loading of kernel modules just on non-privileged user request),
> it is used in real scenarios.
> 
> I can write a long story why it is used in cryptsetup, but long
> story short:
> 
> - It is used for benchmarking, where we actually need kernel crypto.
> 
> As it will be used in real dm-crypt mapping later, benchmarking
> userspace lib just does not make sense.
> (Requiring CAP_SYS_ADMIN here is not such a big issue, and it is
> a very rough test - but useful for relative comparison, not for the
> real numbers.)

Would an API to ask the kernel to benchmark its own algorithms work
for this?  That would be a more accurate benchmark as it removes
syscall overhead.

> - It is used in TrueCrypt/VeraCrypt compatibility (at least).
> 
> This format needs to decrypt the header (first sector) with
> the same algorithms as it is later mapped through dm-crypt.
> Not everything is available in userspace (we support all historic
> versions) and using AF_ALG was very convenient here.
> 
> By removing AF_ALG, you will completely break this format support.
> including some distros (I think Tails uses that :).
> 
> We are using userspace libraries, but removing AF_ALG would be a pain.
> It can be done, but it requires time.

What is the source of the difficulty here?  Just curious.

>> 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.
> 
> The cause with the swap is not such a big deal in reality.
> 
> Nettle is NO WAY for cryptsetup (we have support for it as an alternative
> backend, but it cannot be the default). You do not see the whole picture.

I definitely don't see the whole picture.  It came to mind because
it has a nice, easy-to-use API.

I'm also curious what keeps it from being the default.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eric Biggers]

On Mon, May 04, 2026 at 02:13:01AM -0400, Demi Marie Obenour wrote:
> > - It is used for benchmarking, where we actually need kernel crypto.
> > 
> > As it will be used in real dm-crypt mapping later, benchmarking
> > userspace lib just does not make sense.
> > (Requiring CAP_SYS_ADMIN here is not such a big issue, and it is
> > a very rough test - but useful for relative comparison, not for the
> > real numbers.)
> 
> Would an API to ask the kernel to benchmark its own algorithms work
> for this?  That would be a more accurate benchmark as it removes
> syscall overhead.

For what it's worth, I've always been frustrated by
'cryptsetup benchmark' and the numbers that people report with it
because they underestimate the fast algorithms so significantly.

For example, on my desktop (if I enable AF_ALG so that it works) it
reports 15585 MiB/s for AES-256-XTS encryption.

Yet, a userspace port of the kernel's VAES+AVX512 optimized AES-256-XTS
assembly code runs at 33600 MiB/s: over twice as fast.

(Yes, encryption is that fast now on the newer AMD processors.)

So in this case most of the time is spent in AF_ALG overhead, not the
actual algorithm that the benchmark is supposed to be measuring.

(And this is yet another example of why going through AF_ALG instead of
just calling a userspace crypto library isn't very efficient...)

I know the cryptsetup folks consider this tolerable since 'cryptsetup
benchmark' is meant to be a rough estimate anyway.  But I think it
clearly shows that AF_ALG has never been all that great for the
"benchmarking the kernel's crypto code" use case, either.

In the case of benchmarking done during kernel development, we've
actually already been solving that in a different way: adding KUnit
tests with benchmarks included.

But for benchmarking by end users, yes, I suppose if really needed it
could be done using a new UAPI.  It would just provide the speed of each
algorithm and nothing else.

- Eric

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

[Milan Broz]

On 5/4/26 8:43 AM, Eric Biggers wrote:
> On Mon, May 04, 2026 at 02:13:01AM -0400, Demi Marie Obenour wrote:
>>> - It is used for benchmarking, where we actually need kernel crypto.
>>>
>>> As it will be used in real dm-crypt mapping later, benchmarking
>>> userspace lib just does not make sense.
>>> (Requiring CAP_SYS_ADMIN here is not such a big issue, and it is
>>> a very rough test - but useful for relative comparison, not for the
>>> real numbers.)
>>
>> Would an API to ask the kernel to benchmark its own algorithms work
>> for this?  That would be a more accurate benchmark as it removes
>> syscall overhead.
> 
> For what it's worth, I've always been frustrated by
> 'cryptsetup benchmark' and the numbers that people report with it
> because they underestimate the fast algorithms so significantly.

Yes, but note that dm-crypt will cause a lot of more slowdown
by processing of requests later, so in the end it is not so different.
It was kind of intentional, it is a cryptsetup benchmark, not a kernel
crypto benchmark  :-)

But seriously, benchmark is a hack, but we need at least something.
You can see AES-NI speedup in comparison to otherwise fast symmetric ciphers,
you can see parallelization in CBC decryption This is still useful for users.

I refused to touch it so at least we can compare relative differences
among kernel versions.

If there is any usable interface that can do better job, we will use it.

In the future, I would need to measure both - userspace crypto and kernel.

Milan

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

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1608 bytes --]

On 5/2/26 15:13, Richard Kettlewell wrote:
> On 01/05/2026 16:30, Demi Marie Obenour wrote:
>> On 4/30/26 03:19, 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.
>>
>> 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.
> 
> I have that use case, although fortunately it's in a context where 
> splice() is disabled. But the requirement is for access to the SoC's 
> accelerator - the interface doesn't need to be via AF_ALG in particular, 
> it doesn't have to offer software crypto (and it might be better if it 
> didn't), and it needn't be independent of the specific hardware 
> (although in the bigger picture it'd be a shame if it wasn't).
> 
> ttfn/rjk

Can you provide benchmarks showing that the accelerator is faster
than the CPU on realistic workloads?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Peter Gutmann]

Demi Marie Obenour writes:

>Can you provide benchmarks showing that the accelerator is faster than the
>CPU on realistic workloads?

That could be tricky.  The accelerator uses more hardware crypto than the CPU
on realistic workloads, would that do?

The following is from playing around on a few bits of hardware that were to
hand some years ago, so don't take it as gospel, but:

/* Check for the presence of crypto hardware support.  This is something of
   an exercise in futility because the crypto hardware is anything from
   slightly slower (large data blocks) to much, much slower (more standard
   small data blocks) than software due to the overhead of getting the data
   through the API to and from the cryptologic, the cryptologic startup/
   shutdown overhead, and in the case of /dev/crypto, in and out of the
   kernel.  The only place where it does matter is things like Cortex M3-
   level SoCs, so a combination of lower-power CPUs, no instruction-level
   assist for crypto, and direct hardware access from the RTOS with no
   overhead where you just point the cryptologic at a block of memory and
   say "process this".

   However, people really want to see the fancy crypto hardware used even if
   it yields a net loss in performance so we try and enable it if possible
   unless it really is pointless, just a software emulation (many
   /dev/crypto instances) where, assuming the crypto is provided by OpenSSL,
   you can end up in a situation where OpenSSL is calling into a kernel
   interface that then provides access to another, older and possibly
   unpatched, copy of OpenSSL code that's doing the crypto.

   [...]

So one solution would be to get the fingers-of-one-hand applications still
using the interface off it onto user-mode software-only and then make it
kernel-only, closing the door on the entire attack surface from user space.

Peter.