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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- 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 --]