|
Message-ID: <a2f119d3-d359-ee02-db46-66299c1c3536@ispras.ru> 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.