[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFtpj5y4HtzVDChg@gondor.apana.org.au>
Date: Wed, 25 Jun 2025 11:14:23 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
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 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.
In this particular instance, I thought nobody used hmac on wp512
which is why I didn't do the conversion for it initially. But
apparently someone does use it.
> 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.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists