Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 10 Aug 2019 12:11:11 +0200
From: Szabolcs Nagy <>
Cc: Luiz Angelo Daros de Luca <>
Subject: Re: dlsym returning unresolved symbol address instead of
 dependency library symbol address

* Luiz Angelo Daros de Luca <> [2019-08-10 05:16:19 -0300]:
> I'm ruby maintainer in OpenWrt 18.06 (musl 1.1.19). I got a bug report (
> related to musl in mipsel
> 32bit.
> When ruby loads a module (.so), it checks if that module was built for the
> same ruby that is loading it. Ruby loads libruby at startup, which exports
> ruby_xmalloc sym. So, the check consists on loading the module, searching
> for ruby_xmalloc in the module context and comparing with global
> ruby_xmalloc address. If they do not match, the module is using a different
> libruby. Something like this:
> handle = (void*)dlopen(file, RTLD_LAZY|RTLD_GLOBAL)
> void *ex = dlsym(handle, EXTERNAL_PREFIX"ruby_xmalloc");
> if (ex && ex != ruby_xmalloc) {
>    // module is incompatible!
> }
> The first time a module is loaded, it simply works as expected.
> I debugged and musl is working nicely. At do_dlsym(struct dso *p, const
> char *s, void *ra), it correctly fails to find the symbol with:
> sym = sysv_lookup(s, h, p)
> and correctly find it with:
> sysv_lookup(s, h, p->deps[0])
> Now, when the second module is loaded, it find "ruby_xmalloc" already with:
> sym = sysv_lookup(s, h, p)
> However, sym now points to the address of the undefined symbol in the
> second library (sym->st_shndx is NULL) instead of searching for it in
> dependencies. It seems that do_dlsym() only checks for undefined symbol
> (sym->shndx==NULL) when DL_FDPIC is 1 and DL_FDPIC is 0 in my case.
> Does it make any sense to return an undefined symbol from dlsym()?
> Or does it make sense to return an undefined symbol from sysv_lookup()?
> Or is there any other arch specific issue that happened before, when
> library was loaded?

yes, if the search involves the main executable then
st_shndx==0 && st_value!=0 symbols must be included
because it's a plt in the exe and that's how function
addresses work.. on most targets except mips.

undef syms have st_value==0 in shared libs, maybe
not in mips? can you post the readelf -aW output of
the module that has st_shndx==0 && st_value!=0 entry
in its dynamic symbol table

i think this was going to be fixed by
but that was never applied.

> I created a simple patch that skips a symbol if it is undefined.

i think the find_sym logic should be copied
because mips behaves differently from other targets:

> It fixes the issue and it did not break my system(it still boots). However,
> I didn't test it with multiples archs nor I runned an extensive test.
> I'm not subscribed. Please, CC me.
> Regards,
> ---
>      Luiz Angelo Daros de Luca

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.