From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13714 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alexey Izbyshev Newsgroups: gmane.linux.lib.musl.general Subject: Re: dlsym(handle) may search in unrelated libraries Date: Wed, 6 Feb 2019 16:40:42 +0300 Message-ID: <92a77fed-30ab-ed24-b8dd-a1bac3cb0338@ispras.ru> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="44107"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 To: musl@lists.openwall.com Original-X-From: musl-return-13730-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 06 14:40:28 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 1grNRE-000BKZ-Qi for gllmg-musl@m.gmane.org; Wed, 06 Feb 2019 14:40:28 +0100 Original-Received: (qmail 32214 invoked by uid 550); 6 Feb 2019 13:40:26 -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 32177 invoked from network); 6 Feb 2019 13:40:26 -0000 In-Reply-To: Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:13714 Archived-At: Alexander Monakov noticed a confusing detail in my report: I used "libc.so.6" in my example despite that musl's "make install" creates "libc.so" only. To clarify, "libc.so.6" has nothing to do with glibc, and "libc.so.6" may be replaced with just "libc.so" in my example without any change in semantics. Alexey On 2/6/19 12:02 AM, Alexey Izbyshev wrote: > 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