Hi Florian, On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote: > * Alejandro Colomar: > > > Here's a new revision of the proposal. I've removed ENOMEM, since it's > > not strictly necessary; it's only necessary that those systems that > > already set it continue setting it (and my proposal for POSIX will > > certainly include ENOMEM). > > As far as I can see, this changes specification across all allocation > functions and requires them to be able to produce zero-sized objects. > Previously, the discussion was about changing realloc only.
Yes, but the changes in malloc(0) are a no-op for most implementations,
including glibc.
AIX is the only one we know that would need to be updated. Plus maybe
some small embedded imoplementations.
The previous discussion was about realloc(p,0) because that's the main
issue, which results in vulnerabilities, but committee members asked me
to merge both proposals at once --I had a _separate_ proposal for
malloc(0), which of course I didn't mention to glibc, as it's not a
problem here--, so that people would see the entire goal at once, so as
to avoid confusion.
But continue reading.
> Is this really the right direction, given that
>
> int a[n];
>
> is still undefined, and that C does not support zero-sized objects in
> general?
My plan is to address that after realloc(p,0).
In fact, Doug McIlroy suggested me in private to try to propose
standardizing
int a[0];
first, and then use it to convince that malloc(0) and realloc(p,0) should
follow.
However, I see more opposition for that than for malloc(0) and
realloc(0). One of the reasons is there are some platforms that
support malloc(0) and realloc(p,0), but none that support a[0].
>
> Wouldn't it be more consistent to move in the other direction, and
> require that allocations of zero size fail because C does not support
> zero-sized objects?
That's what some people have attempted since the times of SysV and C89.
Three decades after, people haven't achieved that, and we see the
fallout.
Plus, the only direction in which moving is relatively safe is from
returning-NULL behavior to returning-non-null behavior. Consider this
code written for a realloc(p,0) that returns NULL:
errno = 0;
new = realloc(old, n);
if (new == NULL) {
if (errno == ENOMEM)
free(old);
goto fail;
}
...
free(new);
If you suddenly return non-null from realloc(p,0), that code will
continue behaving well. In some other cases, as you can see in my
proposal, a memory leak would be introduced, which is a very mild
problem.
Now see some code written for platforms like musl or the BSDs:
new = realloc(old, n);
if (new == NULL)
free(old);
goto fail;
}
...
free(new);
Now, if realloc(p,0) starts returning NULL and freeing the object, like
in glibc, line 3 will result in a double-free. This is a serious bug,
which can result in RCE vulnerabilities.
See the Whatsapp RCE mentioned in the proposal. Here's another link
that talks about it which Bruno found, which mentions reallocarray():
<https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/>
So, we can't move in the direction of glibc or AIX, as it would break
the world.
> (This is why I don't want to make any changes today—we just don't know
> what the tightened specification will look like in the published
> standard. There are just too many totally reasonable variations.)
The thing is, someone in the C Committee asked me yesterday if glibc is
really into this if the committee agrees to move to the BSD behavior.
If you --glibc maintainers-- publicly agree to do this change with the
condition that the C Committee standardizes exactly this first, I'm
pretty sure I can convince the committee to standardize it. The
committee is worried that if it standardizes that, then glibc might
still ignore it.
So, both parties are worried that the other might not agree. The
solution I see is that you agree to the change conditional to having the
change in the standard first, and then the committee can change the
standard.
Would you agree to that?
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
