This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)


On 07/16/2015 04:00 AM, Siddhesh Poyarekar wrote:
> Some valid ELF objects, like .debug files may refer to sections
> outside themselves since they're loaded and patched up to their parent
> ELF.  Calling ldd on them may result in a segfault since it may try to
> read beyond the end of the mapping.  Red Hat bz:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=741105
> 
> has an example, although I haven't been able to find a sample
> reproducer file immediately.  This patch has been carried in Fedora
> and RHEL for a couple of years now.  Also tested on x86_64 to verify
> that there are no regressions.
> 
> 	[BZ #18685]
> 	* sysdeps/generic/dl-fileid.h (_dl_get_file_id): Accept
> 	pointer to a struct stat64.
> 	* sysdeps/posix/dl-fileid.h (_dl_get_file_id): Likewise.
> 	* elf/dl-load.c (_dl_map_object_from_fd): Avoid mapping past
> 	end of ELF file.

This is not the right fix for this problem. The right fix has not
been attempted because it involves someone doing some real leg work
to gather consensus. This fix adds complex checking in ld.so for
minimal gain, and eventually you'll get a debuginfo file that is
different again in some odd way.

The fix is to allocate a new ET_DEBUG_EXEC and ET_DEBUG_DYN and mark
the debuginfo with those flags. That way ldd knows that the debuginfo
is going to be incomplete and take action e.g. like printing out a
message saying "This is debuginfo for a library" without processing
any of the sections.

Then you update binutils to add the ET_* flags to debuginfo objects.
It can't be a generic elf header bit because most arches have used
them all up. It can't be a .note because that is allocated and may
reorganize the debuginfo in ways which mean it can't easily be layered
on top of the original executable from which it was stripped. Not to
mention .note's are too hard to find for some tools. The best option
is a new set of ET_* flags.

If you can't get those values standardized, and yes we'd have to go
to the Generic ELF ABI people and ask for them, then we could use
ET_GNU_* and use the OS-specific value range.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]