[Bug dynamic-link/23810] New: dl-close: if dl-load procedure failed, dl-close doesn't delete the half-cooked objects with DF_1_NODELETE

["lion at aosc dot io" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 23810
           Summary: dl-close: if dl-load procedure failed, dl-close
                    doesn't delete the half-cooked objects with
                    DF_1_NODELETE
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: lion at aosc dot io
  Target Milestone: ---

Created attachment 11361
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11361&action=edit
Shell script to reproduce the bug

This will happen when a program loads a plugin linked against DF_1_NODELETE
shared objects (e.g. /usr/lib/libglib-2.0.so in my computer) and then failed in
initialisation progress (phase?) because of, for example, missing some other
shared objects. The half-cooked shared objects will be still in link_map
chains.

Now, consider another normal object is being loaded, ld.so will try to resolve
their symbols in the chains and crash because libglib-2.0.so had not been
relocated and many fields remain uninitialised. In fact, it crashes in many
ways.

In short, even a object is marked as NODELETE, if it has not been completely
"loaded", it should be deleted.

(A simple reproduce script is attached, you will need a C compiler. Tested on
Arch Linux, Ubuntu 18.04, AOSC OS)

I am willing to propose a patch in /elf/dl-... but I am not sure about the
workflow here.

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