[Bug dynamic-link/14511] New: dlclose DSO unloading fundamentally unsafe

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14511

             Bug #: 14511
           Summary: dlclose DSO unloading fundamentally unsafe
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugdal@aerifal.cx
    Classification: Unclassified


dlclose attempts to unload/unmap the DSO when closing the last reference.
Unfortunately, this operation is fundamentally unsafe. Consider a program
"main" that links to a library "foo" and dynamically loads another library
"bar" which depends on "foo". In this situation, "bar" is a candidate for
unloading, but "foo" is not. Suppose "bar" was not designed specifically for
use as a dynamic loaded module, just an ordinary library, and suppose "bar"
leaks a reference to functions or objects in its mapping down to "foo" -- for
example, by registering a widget/codec/converter/etc. of some sort for use by
"foo". After "main" closes "bar", the leaked reference remains in storage
belonging to "foo", and will result in UB (crash or worse) when "foo" later
attempts to dereference it.

Note that the problem would not arise if both "foo" and "bar" had been loaded
dynamically with the same reference count (i.e. with "bar" as the only user of
"foo") since "foo" would also get unloaded at this point; nor would it arise if
both were linked into "main".

I'm attaching minimal test cases to demonstrate the problem. The "registration
with foo" concept is idiotically oversimplified in the test case, but you can
imagine it being some fancier data structure that allows multiple registration
and perhaps even unregistration.

Moreover, this kind of issue is not the ONLY way dlclose can break things; it's
just one example. Another example would be a library which starts a thread the
first time it's called and never reports the fact that it started a thread to
the calling application. This will of course crash immediately when dlclose is
called.

For better or worse, there is no way to fix the problem outright without
disabling unmapping on dlclose entirely. As a fix, I recommend disabling
unmapping, and creating a new DT_GNU_UNLOADABLE tag or other similar mechanism
that DSOs can use to tag themselves as safe for unloading. Then, DSOs being
built with the intent of being plugins/loadable-modules can be written to be
unload-safe and tagged as such, and the dynamic linker will no longer trash the
process when closing a plain library file that was not intended to be
unloadable.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.