Broken ELF binaries that have RLD_MAP equals to 0 (it seems to be possible to
generate them linking it with --version-script) are causing a segfault of ld.so,
even in --list or --verify mode. While this is obviously a bug in the ELF
binary, ld.so should not segfault in this case.
Created attachment 4805 [details]
My impression when I looked at another issue relating to ldd and its use of ld.so was that ld.so is not expected to do anything sensible with broken binaries or libraries in any mode, as an architecture-independent matter, and running with them may involve arbitrary code execution (so you mustn't use ld.so on possibly hostile code). Maybe we should generically fix this so that ldd of hostile code is safe, but then you'd also need to allow for arbitrary values that are not 0 but still involve writing somewhere inappropriate - that is, somehow check the address for sanity.
Note that the problem is not only with ldd, it also segfaults while calling the binary. For the record, the original bug report is the following:
On Wed, 15 Feb 2012, aurelien at aurel32 dot net wrote:
> Note that the problem is not only with ldd, it also segfaults while
> calling the binary. For the record, the original bug report is the
Segfaulting while calling invalid binaries is certainly to be expected
(there's no way you can sensibly expect to execute them safely, at most
you might detect some conditions and give an error message), whereas you
can argue that ldd should handle them safely. The binutils bug creating
such binaries has been fixed:
Closing as binutils were fixed two years ago.