Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130122234337.GR20323@brightrain.aerifal.cx>
Date: Tue, 22 Jan 2013 18:43:37 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: dladdr()

On Tue, Jan 22, 2013 at 05:11:42PM +0100, Szabolcs Nagy wrote:
> * pierre <pierre@...entlife.com> [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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.