[Bug libc/31987] New: The name recorded in the link_map does not match what is returned by dlinfo(3)

["woodard at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 31987
           Summary: The name recorded in the link_map does not match what
                    is returned by dlinfo(3)
           Product: glibc
           Version: 2.39
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: woodard at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 15631
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15631&action=edit
reproducer

link_map->l_name for main executable is an empty string and therefore does not
match the name returned by dlinfo(3) for the same object. Additionally
la_objopen() in an auditor is passed the same empty string. This really should
be populated with the name of the file being opened as it is in all other
cases. 

A second very closely related problem is in non-PIE executables the base
address found in the link_map is NULL while dlinfo(3) returns the correct
value. This should be set to be where the object is loaded.

Attached is a small reproducer simply:

tar xvzf inconsistent-objopen.tar.gz
cd inconsistent-objopen
make

The output will look something like:

ben@pun:~/Shared/Work/test/auditor-tests/tier2/inconsistent-objopen$ make

Success requires OK (not FAIL) at the end of output:
LD_AUDIT=./libauditor-vdso.so ./main-simple
  la_objopen('')
  la_objopen('/lib64/ld-linux-x86-64.so.2')
  la_objopen('linux-vdso.so.1')
    Seen vDSO from objopen!
  la_objopen('/lib64/libc.so.6')
la_preinit, scanning main link_map...
  l_name = ''
  l_name = 'linux-vdso.so.1'
    Seen vDSO in link map!
  l_name = '/lib64/libc.so.6'
  l_name = '/lib64/ld-linux-x86-64.so.2'
dladdr(vDSO) pathname matches link_map entry. OK.
dladdr(vDSO) base address matches link_map entry. OK.
vDSO notified via objopen. OK.

Success requires OK (not FAIL) at the end of output:
./main-dlinfo-pie
Name recorded in Dl_info:  './main-dlinfo-pie' at base 0x556ac1fbd000
Name recorded in link_map: '' at base 0x556ac1fbd000
Pathnames do not match. FAIL.
Base addresses match. OK.
./main-dlinfo-nopie
Name recorded in Dl_info:  './main-dlinfo-nopie' at base 0x400000
Name recorded in link_map: '' at base (nil)
Pathnames do not match. FAIL.
Base addresses do not match. FAIL.

The first problem is when the la_objopen() auditor function is called it is
passed an empty string for the object's name. This really should be populated
with the name of the file being opened as it is in almost all other cases. This
empty name is then what is stored in the link_map->l_name entry.  Subsequently,
when dlinfo(3) is called then it surprisingly is able to identify the object's
name. 

Then the base addresses do not match.

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