Re: Re: NULL deref SEGV in malloc.c:unbin()

[Rich Felker <dalias@aerifal.cx>]

On Mon, Dec 30, 2013 at 07:17:49PM +0000, David Wuertele wrote:
> I found the root cause of the SEGV, I was calling closedir() on the
> same dir pointer twice (quite some time before the SEGV).
> 
> I assume that the behavior of closedir() is undefined when used this
> way, so my program now makes sure not to do that.
> 
> But it seems a poor implementation that a double call to closedir
> should result in memory corruption, and it seems a bug in malloc()
> that a closedir/opendir sequence can cause it to SEGV.

No, there is fundamentally no way to make double-free errors safe;
once a resource has been freed, the (numerically) same identifier may
be used for new resources, and there is no way in general to
distinguish between valid access via the new resource and invalid
access to the already-freed old resource. In multi-threaded situations
especially, this makes double-free errors (of any sort, even plain
file descriptors via close()) one of the most dangerous programming
errors possible. These types of errors have been responsible for many
real-world remote privilege elevation vulnerabilities.

musl attempts to catch and intentionally crash on those double-free
errors that *can* be caught (a subset of all possible ones) so it's a
bit odd that you're experiencing free-list corruption rather than a
direct crash. I suspect you're actually using the already-closed DIR
handle in other ways before closing it again, perhaps calling readdir
on it, which would access and modify the contents of this memory
(which now belongs to the allocator) as if it were a DIR handle.

Rich