Bug 14932

Summary: dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"
Product: glibc Reporter: Paul Pluzhnikov <ppluzhnikov>
Component: dynamic-linkAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: carlos, drepper.fsp, fweimer
Priority: P2 Flags: fweimer: security-
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description Paul Pluzhnikov 2012-12-07 22:03:32 UTC
This is a repeat of GNATS libc/1188 issue from 13 years ago:

http://marc.info/?l=glibc-alpha&m=98313801301771&w=2
http://marc.info/?l=glibc-alpha&m=98313802001691&w=2

I accept that there is ambiguity in what dlsym(..., "foo") is ambiguous, but shouldn't two dlsym()s below return the *same* answer?

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>

int main()
{
  void *p = dlsym(RTLD_NEXT, "fopen");
  void *h = dlopen("libc.so.6", RTLD_LAZY);
  void *q = dlsym(h, "fopen");

  printf("%p -- p (via RTLD_NEXT)\n", p);
  printf("%p -- q (via dlsym(%p))\n", q, h);

  return 0;
}

gcc -m32 -g t.c -ldl && ./a.out
0xf76e41a0 -- p (via RTLD_NEXT)
0xf7634e70 -- q (via dlsym(0xf7758c88))

Google ref: b/7695672
Comment 1 Carlos O'Donell 2014-10-27 18:47:42 UTC
Worse is that dlsym for a symbol that has no default returns NULL, for example in the case of libpthread.so and you must then use dlvsym to get the symbol.

I agree this should be fixed and dlsym should behave like the application would normally behave had it just been compiled. You get the default version of the symbol and RTLD_NEXT gives you the next version and so on.
Comment 2 Florian Weimer 2016-06-08 19:42:15 UTC
*** Bug 20220 has been marked as a duplicate of this bug. ***