dlsym(handle) may search in unrelated libraries

[Alexey Izbyshev <izbyshev@ispras.ru>]

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 <dlfcn.h>
#include <stdio.h>

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