[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <16a713ee-4cf3-4f40-a532-8a937eaffd21@gmail.com>
Date: Mon, 4 May 2026 02:13:01 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: Milan Broz <gmazyland@...il.com>, oss-security@...ts.openwall.com,
Eric Biggers <ebiggers@...nel.org>
Cc: Jan Schaumann <jschauma@...meister.org>, iwd@...ts.linux.dev
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
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)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
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.
