From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4428 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: Sat, 28 Dec 2013 20:34:45 -0500 Message-ID: <20131229013445.GJ24286@brightrain.aerifal.cx> References: <20131227190544.GF24286@brightrain.aerifal.cx> <20131227221345.GG24286@brightrain.aerifal.cx> <20131229000112.GY1685@port70.net> <20131229000511.GZ1685@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 1388280894 8071 80.91.229.3 (29 Dec 2013 01:34:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Dec 2013 01:34:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4432-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 29 02:35:01 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 1Vx5HR-0004Tn-49 for gllmg-musl@plane.gmane.org; Sun, 29 Dec 2013 02:35:01 +0100 Original-Received: (qmail 5226 invoked by uid 550); 29 Dec 2013 01:34:58 -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 5218 invoked from network); 29 Dec 2013 01:34:58 -0000 Content-Disposition: inline In-Reply-To: <20131229000511.GZ1685@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4428 Archived-At: On Sun, Dec 29, 2013 at 01:05:15AM +0100, Szabolcs Nagy wrote: > * Szabolcs Nagy [2013-12-29 01:01:12 +0100]: > > > > so it seems the corruption starts before opendir > > > > it would be nice to see where 0x2139018 comes from and why > > mal.binmap and mal.bin[40] aren't managed properly > > probably unrelated but i dont understand > > split = (void *)((char *)self + n); > > in pretrim and trim > > why is the n enough between the start of self and split > chunks? (and not n + overhead) The first line of malloc() calls adjust_size(&n). After that, n is always in terms of total chunk size needed, not caller-usable size. Rich