linux-kernel - Re: [GIT PULL] Crypto Fixes for 6.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjn5AtuNixX36qDGWumG4LiSDuuqfbaGH2RZu2ThXzV-A@mail.gmail.com>
Date: Sun, 10 Aug 2025 07:51:56 +0300
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vegard Nossum <vegard.nossum@...cle.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [GIT PULL] Crypto Fixes for 6.17

On Sat, 9 Aug 2025 at 21:22, Vegard Nossum <vegard.nossum@...cle.com> wrote:
>
> The actual explanation is given in the email here:

Yeah, that should have been in the commit message somewhere.

And honestly, it should have been in the code too. Having very random
constants in header files with no explanation for them is not great.

> This is an anti-pattern of the crypto code that AFAICT ultimately stems
> from the removal of VLAs:

I'd say that it stems from using random sizes with no logic and the
VLAs were just the *previous* problem case of the same issue.

> As a minimal future-proofing fix, maybe we could add something like
>
> BUILD_BUG_ON(sizeof(struct md5_state) <= HASH_MAX_DESCSIZE);
>
> to every hashing algorithm, and/or a dynamic check in the crypto API
> (completely untested):

The dynamic check may be the right thing to do regardless, but when
fixing outright bugs, at least document what went wrong and why. Not
just "360 was too small for X, so it is now 361".

                Linus