From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2649 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dladdr() Date: Tue, 22 Jan 2013 18:43:37 -0500 Message-ID: <20130122234337.GR20323@brightrain.aerifal.cx> References: <50F6E698.3070604@gmail.com> <20130121020335.GO20323@brightrain.aerifal.cx> <1358751500.2196.20.camel@6-core> <20130121183523.GP20323@brightrain.aerifal.cx> <1358836066.2172.45.camel@6-core> <20130122130730.GB10600@port70.net> <1358862044.2172.216.camel@6-core> <20130122135151.GQ20323@brightrain.aerifal.cx> <1358866786.2172.242.camel@6-core> <20130122161141.GC10600@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 1358898234 2038 80.91.229.3 (22 Jan 2013 23:43:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Jan 2013 23:43:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2650-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 23 00:44:13 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 1TxnVh-0000O4-Ni for gllmg-musl@plane.gmane.org; Wed, 23 Jan 2013 00:44:09 +0100 Original-Received: (qmail 24272 invoked by uid 550); 22 Jan 2013 23:43:50 -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 24259 invoked from network); 22 Jan 2013 23:43:50 -0000 Content-Disposition: inline In-Reply-To: <20130122161141.GC10600@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2649 Archived-At: On Tue, Jan 22, 2013 at 05:11:42PM +0100, Szabolcs Nagy wrote: > * pierre [2013-01-22 15:59:46 +0100]: > > > in the event the stack has been smashed, > > > following the stack frames is likely > > > (almost certain) to lead you to [bad] > > > destinations [...] that might not even > > > be valid > > > > That's precisely what I wrote in that email > > that nobody seems to have read. > > > > i can assure you that at least i read your mail > > we know that you think that the stack is smashed > but you found it important to mention that in debug > mode it works while it crashes in release mode > (whatever those modes mean) If the crash is occurring in dladdr, more than just the stack must be smashed, since dladdr does not access any pointers that would be located on the stack. As far as I can tell, in order for it to crash, the linked list of loaded DSOs must be corrupted. It's possible that this is more likely with musl than with glibc because DSO records typically will get allocated in the otherwise-unused slack space at the beginning/end of DSO .data segments, where overflows of static objects could run into the DSO records. > > And I added, just in case it could help, that > > dladdr should not crash when trying to lookup > > invalid addresses. > > addr is never dereferenced in musl's code > so invalid addr is not an issue Indeed, that's the question I was trying to check on to make sure we weren't doing something wrong. Rich