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

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

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: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature