From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13650 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Infinite loop in malloc Date: Fri, 25 Jan 2019 22:57:25 +0100 Message-ID: <20190125215725.GV21289@port70.net> References: <20190125151350.GB20330@r> <20190125214929.GE23924@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="95436"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13666-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 25 22:57:40 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gn9To-000Ojq-91 for gllmg-musl@m.gmane.org; Fri, 25 Jan 2019 22:57:40 +0100 Original-Received: (qmail 23849 invoked by uid 550); 25 Jan 2019 21:57:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23828 invoked from network); 25 Jan 2019 21:57:37 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190125214929.GE23924@voyager> Xref: news.gmane.org gmane.linux.lib.musl.general:13650 Archived-At: * Markus Wichmann [2019-01-25 22:49:29 +0100]: > On Fri, Jan 25, 2019 at 10:13:50AM -0500, r yang wrote: > > Examining the value in gdb: > > (gdb) printf "%X\n", mask > > 204701 > > > > The bin head points to the bin itself so this condition is never met: > > c = mal.bins[j].head; > > if (c != BIN_TO_CHUNK(j)) { ... } > > > > Examining the values in gdb: > > (gdb) printf "%X\n", mal.bins[j].head > > 62337FC0 > > (gdb) printf "%X\n", (struct chunk *)((char *)(&mal.bins[j].head) - (2*sizeof(size_t))) > > 62337FC0 > > Wait, isn't that an invalid state? The bins are circular doubly linked > lists; the head points back to itself only when the list is empty. But > the binmap is only set for non-empty bins. At least in the > single-threaded case. > > So, if the bit is 1, then it was never deleted. So either arm's > a_and_64() is b0rken, or the last chunk removed from the smallest bin it is not a 32bit process based on the backtrace. it's most likely a qemu-arm running on x86_64. so the problem is not arm's a_and_64. it can be a concurrency bug that leaves mal.binmap corrupted. > was invalid, and didn't trigger the a_and_64(). Or does anyone have a > better idea? > > Ciao, > Markus