On Fri, 20 Jun 2025, Milan Broz wrote:
> Hi,
>
> On 6/20/25 6:09 AM, Herbert Xu wrote:
> > The output buffer size of of crypto_shash_export is returned by
> > crypto_shash_statesize. Alternatively HASH_MAX_STATESIZE may be
> > used for stack buffers.
> >
> > Fixes: 8cf4c341f193 ("crypto: md5-generic - Use API partial block handling")
> > Reported-by: Milan Broz <gmazyl...@gmail.com>
> > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
>
> Yes, that fixes the issue, thanks!
>
> Tested-by: Milan Broz <gmazyl...@gmail.com>
>
> Mikulas, I think this should go through DM tree, could you send it for 6.16?
> The full patch is here
> https://lore.kernel.org/linux-crypto/afte3kdzxcazc...@gondor.apana.org.au/T/#u
>
> > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
> > index 9dfdb63220d7..cb4617df7356 100644
> > --- a/drivers/md/dm-crypt.c
> > +++ b/drivers/md/dm-crypt.c
> > @@ -517,7 +517,10 @@ static int crypt_iv_lmk_one(struct crypt_config *cc, u8
> > *iv,
> > {
> > struct iv_lmk_private *lmk = &cc->iv_gen_private.lmk;
> > SHASH_DESC_ON_STACK(desc, lmk->hash_tfm);
> > - struct md5_state md5state;
> > + union {
> > + struct md5_state md5state;
> > + u8 state[HASH_MAX_STATESIZE];
> > + } u;
Hi
345 bytes on the stack - I think it's too much, given the fact that it
already uses 345 bytes (from SHASH_DESC_ON_STACK) and it may be called in
a tasklet context. I'd prefer a solution that allocates less bytes.
I don't see the beginning of this thread, so I'd like to ask what's the
problem here, what algorithm other than md5 is used here that causes the
buffer overflow?
Mikulas
