Date: Mon, 30 Dec 2013 16:25:04 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: NULL deref SEGV in malloc.c:unbin() 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
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.