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

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: <20250625033238.GB8962@sol>
Date: Tue, 24 Jun 2025 20:32:38 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	"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.16

On Wed, Jun 25, 2025 at 11:14:23AM +0800, Herbert Xu wrote:
> On Tue, Jun 24, 2025 at 08:04:04PM -0700, Eric Biggers wrote:
> >
> > Wouldn't it make more sense to revert the "Crypto API partial block handling"
> > stuff?  It's been causing a huge number of problems, and it's been getting
> > superseded by the librarification changes anyway.
> 
> The partial block handling simplifies the implementation of both
> software and hardware hash algorithms.  Just look at the diffstat.

Not software, since the library functions have to handle partial blocks anyway.
There will be a negative diffstat for algorithms that haven't been converted to
have a library API yet, but it will go away once they are.

> > Indeed, I just found that a lot of drivers in drivers/crypto/ haven't been
> > updated to be aware of the extra byte that comes back from
> > crypto_shash_export().  So there are a bunch of buffer overflows there too.
> > (Not like drivers/crypto/ actually matters, but apparently your changes are for
> > its benefit?  So it's interesting that it was actually broken by them.)
> 
> If anything this proves that enforcing a consistent hash format
> is the right thing to do.  All those buggy code paths were assuming
> that the export format is fixed which was not the case prior to the
> partial blocks work.
> 
> But thanks for pointing me to these buggy drivers and I will send
> out fixes for them.

Well, they (reasonably enough) assume the format that all the CPU-based code
previously used.  So they weren't really broken until your changes.

Of course, the lack of type safety here is an artificial problem created by the
generic crypto API which uses a 'void *' state.  The library functions simply
use the C type system, so they just work and do not have this sort of silly
issue where different places disagree about what struct a 'void *' points to...

These legacy drivers should just use the library functions.

- Eric