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,
