[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Feb 2019 20:02:28 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: Markus Wichmann <nullplan@....net>, musl@...ts.openwall.com
Subject: Re: dlsym(handle) may search in unrelated libraries
On 2/6/19 7:02 PM, Markus Wichmann wrote:
>
> Thankfully the patch is simple: Explicitly make ldso and vdso have no
> deps. I was tempted to put this into kernel_mapped_dso(), but then I
> remembered that the app is also a kernel mapped dso, and it usually does
> have deps that need processing. At least, in nontrivial cases.
>
> The attached patch should tide you over.
>
Thank you for the quick response and the patch, Markus! Your patch fixes
the exact test case I posted.
Unfortunately, my test case was a simplified example of a general
problem: dso->deps is assigned only for the main app and for libraries
opened with dlopen(), but not for their dependencies. Consider the
following:
$ cat bar.c
int bar = 42;
$ musl-gcc -fPIC -shared bar.c -o libbar.so
$ cat foo.c
extern int bar;
int *foo = &bar;
$ cat baz.c
extern int bazdep;
int *baz = &bazdep;
$ cat bazdep.c
int bazdep = 1;
$ cat main.c
#include <dlfcn.h>
#include <stdio.h>
int main(void) {
if (!dlopen("libbaz.so", RTLD_NOW|RTLD_LOCAL))
return 1;
if (!dlopen("libfoo.so", RTLD_NOW|RTLD_LOCAL))
return 1;
void *h = dlopen("libbazdep.so", RTLD_NOW|RTLD_LOCAL);
printf("%p\n", dlsym(h, "bar"));
}
$ musl-gcc main.c -Wl,-rpath='$ORIGIN' -ldl
$ ./a.out
0x7f66ed371020
Here, "libbazdep.so" assumes the role of "libc.so" from the previous
test: it's a library with dso->deps == NULL that is loaded before
"libfoo.so". So, when "libbazdep.so" is dlopen'd, musl considers it to
be a "first load" and erroneously includes "libbar.so" to the list of
dependencies of "libbazdep.so".
Alexey
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
