[Bug dynamic-link/20990] New: Double dlclose() detection contains data race, is unreliable, and can corrupt memory.

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 20990
           Summary: Double dlclose() detection contains data race, is
                    unreliable, and can corrupt memory.
           Product: glibc
           Version: 2.25
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: carlos at redhat dot com
  Target Milestone: ---

In elf/dl-close.c we have this code:

if (__builtin_expect (map->l_direct_opencount, 1) == 0)       
  _dl_signal_error (0, map->l_name, NULL, N_("shared object not open"));

See my comments here:
https://www.sourceware.org/ml/libc-alpha/2016-12/msg00885.html

This code only works in the recursive dlclose case where you know the struct
link_map remains accessible, otherwise you're touching reused memory, unmapped
memory, and possibly have a data race.

POSIX requires this:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlclose.html
~~~
If the referenced symbol table handle was successfully closed, dlclose() shall
return 0. If handle does not refer to an open symbol table handle or if the
symbol table handle could not be closed, dlclose() shall return a non-zero
value. More detailed diagnostic information shall be available through
dlerror().
~~~

The current glibc implementation basically makes a double-dlclose into
undefined behaviour.

This double-close() detection should be removed and replaced with an
implementation that uses IDs instead of a struct link_map*, using the caller's
storage for the void* handle to store an ID that can be used for
double-dlclose() checking.

The downside of using IDs it that you are potentially limited to sizeof(void*)
number of outstanding dlopen's. On 32-bit it doesn't matter because you exhaust
the address space before that number of dlopens. On 64-bit you have an almost
unlimited number of IDs to use.

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