Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250623014134.GM1827@brightrain.aerifal.cx>
Date: Sun, 22 Jun 2025 21:41:35 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Alejandro Colomar <alx@...nel.org>, musl@...ts.openwall.com
Subject: Re: Bug in reallocf(3) when calling realloc(3)

On Sun, Jun 22, 2025 at 06:29:00PM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> > Yes this is true. realloc returning null *always* indicates failure
> > (and accordingly, memory has not been freed) in our past and current
> > implementations, and indeed it can fail when resizing down (to zero or
> > otherwise).
> 
> (limited Cc: list)
> 
> What's the rationale for that?  Wouldn't it better not to honor the
> resize request at all?  The application might be able to continue to run
> if no error is reported (although it's of course likely that it will
> encounter failing fresh allocation soon after that).

I addressed roughly the same topic elsewhere in the thread:

https://www.openwall.com/lists/musl/2025/06/21/6

But I'll summarize here in a form directly answering the request for a
rationale:

If you lie and say the realloc "succeeded" when it just left the
allocation size alone, you've destroyed the ability for the
application to know where it has memory tied up and to be able to
recover from that, and deferred an OOM condition that the application
could potentially handled earlier by backing out and freeing large
objects that were actually responsible for tying up all the memory,
into a late one that it likely can't handle because now
supposedly-small objects are permanently tying up huge slots.

Further, if you lie and say the realloc "succeeded" when it just left
the allocation size alone, now the compiler "knows" the size of the
object is only the new, small size, but malloc_usable_size returns
some much larger number. And all sorts of fun things happen when the
compiler optimizes based on this "knowledge"... Having a byte-exact
malloc_usable_size to fix this issue was a key design goal, and it's
broken as soon as you make realloc lie.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.