Re: [dev] [sbase] sha512-224sum: stack-buffer-overflow

From: Roberto E. Vargas Caballero <k0ga_AT_shike2.net>
Date: Mon, 3 Nov 2025 16:09:34 +0100

Hi,

On Mon, Nov 03, 2025 at 04:07:49PM +0200, Santtu Lakkala wrote:
> > Ok, that makes sense. I suppose the buffer passes depends of the 'n' used
> > in the specific hash.
>
> Yes, in case of SHA-512/224, only the 224 first bits of the produced data
> are used. But as the 'n' is in units of 64-bit items, 224 cannot be
> represented as an integer.

64 bit units? Do you mean a power of 2 into a 64 bit integer?

> The buffer would be only 32 bytes, should pose no problems just having the
> temp array as a local variable in the sha512_224_sum() function, something
> like:
>
> void
> sha512_224_sum(void *ctx, uint8_t md[SHA512_224_DIGEST_LENGTH])
> {
> uint8_t buf[32];
> sha512_sum_n(ctx, buf, 4);
> memcpy(md, buf, SHA512_224_DIGEST_LENGTH);
> }
>
> Otherwise sha512_sum_n() needs to be adjusted to take the digest size in
> some other unit.

Ok, in that case having it in the stack makes everything much easier.
I suppose we would have to apply similar changes to the other versions
of the hash, wouldn't we?

> > Sorry, I didn't understand this point. I don't see the relation between 7 and
> > the internal 32-bit ints. Can you elaborate it a bit more? (take in account that
> > I didn't write that code).
>
> Sorry, it was a bit unclear. sha256_sum_n expects the size argument to be in
> units of the internal state array, which is of 32-bit ints. Now as 224 is an
> exact multiple of 32, the overflow can be simply fixed by passing in the
> correct 224/32 = 7 (instead of the current 8).

Ok. At this point is clear that you know much better than me what we should
change. Can you write the patch and I'll review it?

Regards,
Received on Mon Nov 03 2025 - 16:09:34 CET