From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4432 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: NULL deref SEGV in malloc.c:unbin() Date: Mon, 30 Dec 2013 16:25:04 -0500 Message-ID: <20131230212504.GK24286@brightrain.aerifal.cx> References: <20131227190544.GF24286@brightrain.aerifal.cx> <20131227221345.GG24286@brightrain.aerifal.cx> <20131229000112.GY1685@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388438713 15806 80.91.229.3 (30 Dec 2013 21:25:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Dec 2013 21:25:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4436-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 30 22:25:19 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VxkKt-0006ZU-9r for gllmg-musl@plane.gmane.org; Mon, 30 Dec 2013 22:25:19 +0100 Original-Received: (qmail 16021 invoked by uid 550); 30 Dec 2013 21:25:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16013 invoked from network); 30 Dec 2013 21:25:17 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4432 Archived-At: 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