From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13713 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alexey Izbyshev Newsgroups: gmane.linux.lib.musl.general Subject: dlsym(handle) may search in unrelated libraries Date: Wed, 06 Feb 2019 00:02:39 +0300 Message-ID: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="40548"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Roundcube Webmail/1.1.2 To: musl@lists.openwall.com Original-X-From: musl-return-13729-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 05 22:02:54 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gr7rq-000ASt-CV for gllmg-musl@m.gmane.org; Tue, 05 Feb 2019 22:02:54 +0100 Original-Received: (qmail 24280 invoked by uid 550); 5 Feb 2019 21:02:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24249 invoked from network); 5 Feb 2019 21:02:50 -0000 X-Sender: izbyshev@ispras.ru Xref: news.gmane.org gmane.linux.lib.musl.general:13713 Archived-At: Hello! I've discovered a bug in musl dynamic loader (tested on 1.1.21) which is demonstrated by the following simple example: $ cat bar.c int bar = 42; $ musl-gcc -fPIC -shared bar.c -o libbar.so $ cat foo.c extern int bar; int *foo = &bar; $ musl-gcc -fPIC -shared foo.c -L. -lbar -Wl,-rpath='$ORIGIN' -o libfoo.so $ cat main.c #include #include int main(void) { if (!dlopen("libfoo.so", RTLD_NOW)) return 1; void *h = dlopen("libc.so.6", RTLD_NOW); printf("%p\n", dlsym(h, "bar")); } $ musl-gcc main.c -Wl,-rpath='$ORIGIN' -ldl $ ./a.out 0x7fd7ebe96020 dlsym(handle) is supposed to search only in the library referred to by the handle and in its dependencies. "libc.so.6" doesn't have dependencies and doesn't have a definition for "bar", so dlsym(h, "bar") should return NULL, but it finds "bar" in libbar.so instead. The problem occurs because of the following: 1) Initially, "deps" in dso structure for libc.so.6 is NULL. 2) When dlopen("libc.so.6") is called, "first_load" is true, despite that it's not actually the first load (ldso/dynlink.c:1835): /* First load handling */ int first_load = !p->deps; if (first_load) { load_deps(p); 3) load_deps() then iterates over the dso list starting from "libc.so.6", treating all libraries found in DT_NEEDED of each processed dso as dependencies of "libc.so.6". However, the dso list already contains "libfoo.so" loaded earlier, so "libbar.so" (which is needed by "libfoo.so") is treated as a dependency of "libc.so.6". As a result, dlsym(h, "bar") succeeds. It's also notable that "libfoo.so" and "libbar.so" were loaded with RTLD_LOCAL, but this bug effectively makes their symbols available in such searches regardless of the scope of a library used with dlsym(). ISTM that load_deps(p) was written to work only in real "first load" situations, where "p" is initially the last dso in the list, and new dsos are only added to the list in the course of recursive loading of the dependencies of "p". Could this be fixed? Thanks! (Please CC me on replying, I'm not subscribed to the list.) Alexey