From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9348 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dynlink.c: bug in reclaim_gaps leading to segfault in __libc_exit_fini Date: Wed, 17 Feb 2016 10:25:04 -0500 Message-ID: <20160217152504.GD9349@brightrain.aerifal.cx> References: <20160216215550.GC9915@port70.net> <20160217090327.4c6b5790@vostro.util.wtbts.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 1455722722 2218 80.91.229.3 (17 Feb 2016 15:25:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 15:25:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9361-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 17 16:25:22 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aW3yj-0007Bt-OH for gllmg-musl@m.gmane.org; Wed, 17 Feb 2016 16:25:21 +0100 Original-Received: (qmail 32405 invoked by uid 550); 17 Feb 2016 15:25:18 -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 32386 invoked from network); 17 Feb 2016 15:25:18 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9348 Archived-At: On Wed, Feb 17, 2016 at 04:15:33AM -0500, Hugues Bruant wrote: > Finally figured it out: > > 1. musl is reclaiming space from the executable starting at offset > 0x224B20, i.e. at the end of the bss > 2. this reclaimed space gets used for the dso struct of the first shared lib > 3. the last variable in the bss appears to be scratch space for checksum > computation > 4. the code is assuming "unsigned long" to be 4 bytes, which isn't the case > on 64bit platforms > 5. the checksum code overflows out of the bss, corrupting the dso struct > 6. this issue is masked in a glibc environment because the loader doesn't > make the unused part of the program pages available to malloc. > 7. valgrind doesn't catch the problem because it doesn't bound-check globals > > Sorry about the noise. No problem. Nice find though -- you caught a bug even valgrind couldn't, and one that probably could have been nasty if the linker happened to reorder bss differently such that the overflowed object was no longer at the end. Have you sent a patch upstream? Rich