public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug dynamic-link/14511] New: dlclose DSO unloading fundamentally unsafe
@ 2012-08-22 22:24 bugdal at aerifal dot cx
  2012-08-22 22:27 ` [Bug dynamic-link/14511] " bugdal at aerifal dot cx
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: bugdal at aerifal dot cx @ 2012-08-22 22:24 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-02-06 14:42 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-22 22:24 [Bug dynamic-link/14511] New: dlclose DSO unloading fundamentally unsafe bugdal at aerifal dot cx
2012-08-22 22:27 ` [Bug dynamic-link/14511] " bugdal at aerifal dot cx
2012-08-22 22:30 ` bugdal at aerifal dot cx
2012-08-22 22:32 ` bugdal at aerifal dot cx
2012-08-23  5:24 ` ppluzhnikov at google dot com
2012-08-23  6:50 ` jakub at redhat dot com
2012-08-23 12:01 ` bugdal at aerifal dot cx
2012-08-23 12:04 ` jakub at redhat dot com
2014-06-17  5:54 ` fweimer at redhat dot com
2023-08-07 10:10 ` sam at gentoo dot org
2023-08-07 10:10 ` sam at gentoo dot org
2024-02-06 14:42 ` gabravier at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).