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

From: Roberto E. Vargas Caballero <k0ga_AT_shike2.net>
Date: Mon, 3 Nov 2025 12:21:06 +0100

Hi,

On Sun, Oct 26, 2025 at 12:30:57PM +0100, Hiltjo Posthuma wrote:
> On Thu, Oct 23, 2025 at 03:29:08PM +0200, Frank Busse wrote:
> > Hi,
> >
> > and another one reported by KLEE:
> >
> > ---
> > $ printf "" | ./sha512-224sum
> > ERROR: AddressSanitizer: stack-buffer-overflow
> > ---

I think this is a case where we would get a big benefit
of having the backtrace.

> Maybe a starting point is in with processblock():
>
> libutil/sha512.c: sha512_update() (defined in sha512-224.h).
>
> There might be a mismatch in the buffer that is available there.

I think the problem comes more from the fact that the code
is not ready for empty strings and it does something like
strlen(s) - 1 to remove the eos and then it is fucked.
I am going to take a look to see if this is the case. The
backtrace can help a lot here.

>
> Initial commit for sha512-224:
>
> a392cd475e1d164c940ab3e3cb893f533af2445a
>
> It is probably adapted from the sha512 implementation, but with some size mismatch.
>
> We should add more references on how this implementation came to be (if there
> is any?). "public domain sha512/224 implementation based on fips180-3".

Indeed, the base commit does not say anything about where it comes from
so, this makes harder fixing the issue.

> My small peasant brain is too simple for this crypto stuff.

Mine too xD

> Do we even need this variant of sha512-224? Maybe a rm is a simple solution.

I am going to try fixing it in a fast way, but if it becomes
too complex, I think rm can be a solution xD.

Regards,
Received on Mon Nov 03 2025 - 12:21:06 CET