[Bug dynamic-link/31739] New: LD_DEBUG=libs misattributes RUNPATH if first entry was already encountered

[tobil4sk at outlook dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31739

            Bug ID: 31739
           Summary: LD_DEBUG=libs misattributes RUNPATH if first entry was
                    already encountered
           Product: glibc
           Version: 2.40
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: tobil4sk at outlook dot com
  Target Milestone: ---

If the first RUNPATH/RPATH entry of a file has been encountred before, then
LD_DEBUG=libs misattributes the entire RUNPATH/RPATH value to the incorrect
file.

Checked out at 737a696523a12f4c4a4d6350248a545de75d81cd.

Consider this dependency tree:

> main
> -> libb.so
>    -> liba.so

`main` has the following RUNPATH entries: `shared-rpath:main-rpath`. `libb.so`
has the following RUNPATH entries: `shared-rpath:b-rpath`.

While loading `liba.so`, dependency of `libb.so`, `ld.so` gets confused and
misidentifies which file the RUNPATH has coming from.

This is with `LD_DEBUG=files,libs`:

>    114330:     file=liba.so [0];  needed by /path/to/libb.so [0]
>    114330:     find library=liba.so [0]; searching
>    114330:      search path=shared-rpath/glibc-hwcaps/x86-64-v3:shared-rpath/glibc-hwcaps/x86-64-v2:shared-rpath:b-rpath/glibc-hwcaps/x86-64-v3:b-rpath/glibc-hwcaps/x86-64-v2:b-rpath           (RUNPATH from file ./main)
>    114330:       trying file=shared-rpath/glibc-hwcaps/x86-64-v3/liba.so
>    114330:       trying file=shared-rpath/glibc-hwcaps/x86-64-v2/liba.so
>    114330:       trying file=shared-rpath/liba.so
>    114330:       trying file=b-rpath/glibc-hwcaps/x86-64-v3/liba.so
>    114330:       trying file=b-rpath/glibc-hwcaps/x86-64-v2/liba.so
>    114330:       trying file=b-rpath/liba.so

The first line (printed with `LD_DEBUG=files`) correctly identifies that
`liba.so` is required by `libb.so`. On the other hand, the third line (printed
with `LD_DEBUG=libs`) then gets confused about which binary the `RUNPATH`
belongs to. It is using `shared-rpath` and `b-rpath` (but not `main-rpath`), so
it is clearly using the`RUNPATH` of `libb.so`. However, it mistakenly claims
that this is the`RUNPATH` of `./main` rather than `/path/to/libb.so`.

This happens because when it encounters the first RUNPATH entry
(`shared-rpath`) for `libb.so` it has seen this entry before (from `./main`).
This means that the existing `r_search_path_elem` object is reused to save
memory [0], which has a `where` field that attributes it to `./main`. Then when
we get to printing the RUNPATH list for `libb.so`, `open_path()` looks at the
first entry in the array and sees that it comes from `./main` [1]. Therefore it
mistakenly prints: `(RUNPATH from file ./main)`.

Instead of printing the `where` field of the `r_search_path_elem` object, which
may have been reused from elsewhere, it should print the `l_name` field of the
loader from where the RUNPATH was read. I'll post a patch shortly.

[0] elfc/dl-load.c - lines 507-521:
https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a34cb3559c766f60a3aa778ce6a53ca0f63d9b2b;hb=HEAD#l507
[1] line 1819:
https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a34cb3559c766f60a3aa778ce6a53ca0f63d9b2b;hb=HEAD#l1819

-- 
You are receiving this mail because:
You are on the CC list for the bug.