Bug 14932 - dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"
Summary: dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with...
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 20220 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-07 22:03 UTC by Paul Pluzhnikov
Modified: 2016-06-08 19:42 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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. ***