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

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

On 5/4/26 07:28, Richard Kettlewell wrote:
> On 02/05/2026 23:32, Demi Marie Obenour wrote:
> > 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).
> >
> > Can you provide benchmarks showing that the accelerator is faster
> > than the CPU on realistic workloads?
>
> The consistent improvements in latency and throughput started around the 
> 2Kbyte block size (10-20%) and improved as blocks grew, with around 50% 
> latency reduction and 150% throughput increase at 250Kbyte blocks (which 
> is close to our message size limit).
>
> Obviously this reflects the hardware we are using (which has no AES 
> support in the application cores), outcomes may differ on other targets.
>
> ttfn/rjk

Can you use ChaCha20-Poly1305 or Adiantum instead of AES?  That should
be significantly faster on the CPU
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature