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

From: Roberto E. Vargas Caballero <k0ga_AT_shike2.net>
Date: Mon, 3 Nov 2025 14:45:57 +0100

Hi,

On Mon, Nov 03, 2025 at 02:52:21PM +0200, Santtu Lakkala wrote:
> On 26.10.2025 13.30, Hiltjo Posthuma wrote:
>
> > Maybe a starting point is in with processblock():
> >
> > libutil/sha512.c: sha512_update() (defined in sha512-224.h).
> >
>
> This is actually a simple case of passing wrongly sized buffer to
> sha512_sum_n() when finalizing, and happens with any input. The problem lies

Ok, that makes sense. I suppose the buffer passes depends of the 'n' used
in the specific hash.

> with sha512_sum_n() requiring the digest length argument to be in multiples
> of uint64_t, but for 224 bits this would be 3.5. Either the argument needs
> to be changed to be more granular, or the sha512_224_sum() in
> libutil/sha512-224.c needs to use a temporary buffer.

uhmmmm, using an internal buffer can produce some problems in threaded programs.
Maybe we can add a buffer to the ctxt parameter. Do you think the problem can
be solved in that way?

> The SHA-256 based sha224sum actually has the same problem, but there the fix
> is simpler, just changing the argument of sha256_sum_n to 7, as SHA-256
> internally uses 32-bit ints.

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).

Regards,
Received on Mon Nov 03 2025 - 14:45:57 CET