[Bug dynamic-link/30766] New: The reloc_complete probe can be hit when not all libraries have been relocated

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

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

            Bug ID: 30766
           Summary: The reloc_complete probe can be hit when not all
                    libraries have been relocated
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: aburgess at redhat dot com
  Target Milestone: ---

Created attachment 15061
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15061&action=edit
Patch that exposes the issue described in this bug.

The attached patch applies to current(ish) master (d6fe19facc) and exposes the
issue described in this bug report.  With this patch applied I see:

 $ make test t=dlfcn/tst-rec-dlopen
 ... snip ...
 DSO moddummy1.so loaded when it shouldn't be
 make[2]: Leaving directory '/tmp/glibc/src/dlfcn'
 FAIL: dlfcn/tst-rec-dlopen
 original exit status 1
 Called dummy2()
 Called dummy2()
 make[1]: Leaving directory '/tmp/glibc/src'

This bug was found while investigating some GDB behaviour, and relates to the
reloc_complete probe (elf/dl-open.c).  The docs for reloc_complete say:

 reloc_complete:
    The linker has relocated all objects in the specified namespace.
    The namespace's r_debug structure is consistent and may be
    inspected, and all objects in the namespace's link-map are
    guaranteed to have been relocated.

However, there are times that reloc_complete is called when not every object in
the namespace's link-map have been relocated, and worse, there is no way for
the debugger, when walking the link-map, to tell the difference between a
relocated, and non-relocated object.

This results in GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30765

In the glibc test I modified a situation is setup where a recursive dlopen will
be performed; the test overrides malloc and has the new malloc perform a
dlopen.  At the top level (in do_test) we dlopen a library, while this dlopen
is being performed glibc calls malloc.  These malloc calls themselves trigger a
dlopen call (we take care to avoid infinite recursion here).

The problem is, that, while servicing the top-level dlopen, the library is
added to the namespace's link-map list, and then malloc is called *before* the
library has been relocated.  As a result, this second-level malloc call results
in another dlopen call, and, when we hit the reloc_complete probe for this
second-level dlopen call, the first library is already in the link-map list,
but is not yet relocated, in clear violation of the documented API.

In GDB we hook the reloc_complete probe to figure out when the library has been
loaded.  It is possible for a user to stop at this point an examine the
inferior's memory, which can include examining global state that should have
been relocated, but (due to this bug) has not.

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