[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 29 Nov 2020 01:09:49 -0500
From: Rich Felker <dalias@...c.org>
To: Dominic Chen <d.c.ddcc@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] Fix crash in malloc_usable_size() if nullptr
On Wed, Nov 25, 2020 at 07:38:07PM -0500, Rich Felker wrote:
> On Wed, Nov 25, 2020 at 06:41:14PM -0500, Dominic Chen wrote:
> > On 11/25/2020 5:53 PM, Rich Felker wrote:
> > >Thanks. I wasn't aware of this. I did some research to see if this is
> > >actually documented as supported, since the Linux man pages aren't
> > >normative but just descriptive, and sometimes document things that
> > >aren't actually contracts. It seems glibc doesn't even document the
> > >existence of this function at all though.
> > >
> > >FreeBSD documents it but without any special handling of null
> > >pointers. But Solaris documents the same behavior you described. So it
> > >seems this is at least not entirely glibc-specific. Do you know if
> > >there are other implementations that do the same?
> >
> > Unfortunately, my understanding is just that this functionality
> > (looking up heap allocation sizes) is platform-specific and not
> > standardized. UNIX platforms seem to provide malloc_usable_size()
> > (although it's not in SUSv4), whereas Mac provides malloc_size(),
> > and Windows provides _msize(). Of other platforms, only the Windows
> > documentation explicitly mentions null checks, but it calls a
> > platform-specific invalid parameter handler instead of returning
> > zero.
> >
> > On UNIX platforms, although documentation does not consistently
> > describe returning zero for nullptr, I believe most do actually
> > implement it. I took a look at the source for dlmalloc, glibc,
> > jemalloc, and scudo, and can confirm that all four do so.
>
> Thanks for the followup. When implementing nonstandard extensions, we
> generally try to follow existing practice for what applications can
> "portably" expect from them. Here it sounds like accepting null is
> widespread, so I think it makes sense to apply your patch.
OK, this was already fixed once in commit
d1507646975cbf6c3e511ba07b193f27f032d108 but regressed in mallocng so
it's definitely appropriate to fix here. I found this when attempting
to add oldmalloc support to your patch. I'm updating the commit
message to reflect this and merging now. Thanks!
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.
