avoid crashing after mapping past EOF of invalid shared object

Alexandre Oliva aoliva@redhat.com
Fri Feb 3 17:21:00 GMT 2012


This first came up when trying to ld.so --verify the split debuginfo
file of a dynamic library.  The .so.debug file contains the same PHDRs,
with the same PT_LOAD offsets and sizes, even though the .debug file
does not contain those sections.

We try to mmap the sections anyway, and the kernel happily returns
success in the attempts to mmap past EOF.  However, when we attempt to
access those pages, e.g. to zero out the trailing portion, we get a bus
error.

Although the crash is harmless in this case (but perhaps not so much if
a running process attempts to dlopen() a shared object truncated: we'd
better return an error than crash), this is a problem of input
validation: we shouldn't attempt to map a page that isn't present, and
reject the file as ill-formed instead.

There's still room for “exploiting” this situation by truncating the
pseudo shared object between stat()ing it and mapping it in.  However,
I'm not convinced this would be any more of an issue than the crash we'd
get by accessing a page of code or data if a perfectly valid shared
object is truncated after it is loaded.

So the patch has two goals: offer a nicer error for corrupted shared
objects, and document that the truncation in the window between stat and
mmap is not an exploitable crash.

Can anyone think of any reason not to reject shared objects with PT_LOAD
segments past their EOF?  Alternately, can anyone suggest some other
(cheap) way to test whether the last mmap()ed page won't crash upon
zeroing out its end, rather than trying and crashing?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld-map-past-eof-bz767146.patch
Type: text/x-diff
Size: 1054 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120203/88df4636/attachment.bin>
-------------- next part --------------


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer


More information about the Libc-alpha mailing list