Bug#658278: ld.so segfaults on wrong input

[Goswin von Brederlow <goswin-v-b@web.de>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> severity 658278 wishlist
> tags 658278 + moreinfo
> quit
>
> Goswin von Brederlow wrote:
>
>> It has a different interpreter in its elf section. Ld.so could check
>> that to determine wether the elf file is one it should care about.
>
> A common use case is testing updated versions of ld.so by running
> binaries explicitly using the ld.so binary.  I don't see how your
> proposed enhancement is consistent with that.

The interpreter listed in the elf binary would still match
/lib64/ld-linux-x86-64.so.2 (or whatever it is on the arch) even if you
explicitly call an ld.so from a different location.

My suggestion isn't to match against the location the ld.so currently
holds but against the location the ld.so is supposed to be in, where it
would install to.

>> A segfault is never correct behaviour and needs to be fixed in ld.so.
>
> If my program is built against one DSO and the caller uses LD_PRELOAD
> or LD_LIBRARY_PATH to replace it with something completely different,
> I'd expect segfaults from time to time (due to incompatible struct
> layouts, for example).

In those cases the binary segfaults and that is unavoidable. But in this
case the ld.so itself crashes.

> However, maybe it is avoidable.  Often that kind of misconfiguration
> gets caught by other checks, like the following:
>
> 	foo: symbol lookup error: foo: undefined symbol: some_symbol
>
> Before veering too far in that direction, what is your use case?  Was
> something broken by this?  Maybe there is a simpler way to accomplish
> it.

Nothing specific. We stumbled across it trying to fix a remote system
after an accident with "rm -rf /".

MfG
        Goswin