From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20199 invoked by alias); 22 Aug 2012 22:24:46 -0000 Received: (qmail 20188 invoked by uid 22791); 22 Aug 2012 22:24:44 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Aug 2012 22:24:21 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug dynamic-link/14511] New: dlclose DSO unloading fundamentally unsafe Date: Wed, 22 Aug 2012 22:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00156.txt.bz2 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.