[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0be2b33-4f27-489f-85d2-1dfe9826e022@terraraq.uk>
Date: Mon, 4 May 2026 12:28:42 +0100
From: Richard Kettlewell <rjk@...raraq.uk>
To: oss-security@...ts.openwall.com
Cc: demiobenour@...il.com
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
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
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.
