Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Feb 2019 00:23:06 +0300
From: Alexey Izbyshev <>
To: Markus Wichmann <>
Subject: Re: dlsym(handle) may search in unrelated libraries

On 2019-02-06 23:25, Markus Wichmann wrote:
> Right you are. It took me a while to understand what the deps array was
> even for (since musl's dlclose() doesn't do anything, tracking
> dependencies is mostly pointless), but I found it is needed for lazy
> relocation processing. So it is necessary for all libs opened by
> dlopen() directly to contain a list of all their dependencies. All the
> other libs can have an empty list.

Actually, dso->deps is used in dlsym(handle) because it must use the 
dependency order for symbol search, so it's incorrect to have deps empty 
for "all the other" libs. Consider the following modification of my 
previous example:

$ cat bazdep.c
int bazdep = 1;
extern int bazdepdep;
int *p = &bazdepdep;
$ cat bazdepdep.c
int bazdepdep = 2;
$ cat main.c
#include <dlfcn.h>
#include <stdio.h>

int main(void) {
   if (!dlopen("", RTLD_NOW|RTLD_LOCAL))
     return 1;
   if (!dlopen("", RTLD_NOW|RTLD_LOCAL))
     return 1;
   void *h = dlopen("", RTLD_NOW|RTLD_LOCAL);
   printf("%p\n", dlsym(h, "bar"));
   printf("%p\n", dlsym(h, "bazdepdep"));

The correct output is zero in the first line and some non-zero address 
in the second. Vanilla musl 1.1.21 prints two non-zero addresses. But 
with your patch the output is two zeros because dlsym() can't search in 
dependencies of "" anymore.


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.