[Bug dynamic-link/20069] New: dlsym() should not use malloc on failure (breaks Address Sanitizer initialization)

["peter at lekensteyn dot nl" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20069

            Bug ID: 20069
           Summary: dlsym() should not use malloc on failure (breaks
                    Address Sanitizer initialization)
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: peter at lekensteyn dot nl
  Target Milestone: ---

The patch for bug 19509 (dlerror() reporting NULL for dlsym(RTLD_NEXT, ...)
errors) introduced a malloc call. This breaks interposing libraries such as
ASAN[1] that rely on dlsym(RTLD_NEXT) during initialization (in which malloc
might not be usable yet).

 [1]: https://llvm.org/bugs/show_bug.cgi?id=27310

Reproducer:
#define _GNU_SOURCE
#include <stdlib.h>
#include <unistd.h>
#include <dlfcn.h>
#include <string.h>

static void print(const char *str) {
    write(STDOUT_FILENO, str, strlen(str));
}

void *(*malloc_)(size_t size);
__attribute__((constructor)) static void malloc_init(void) {
    malloc_ = dlsym(RTLD_NEXT, "malloc");
}
void *malloc(size_t size) {
    print("malloc called\n");
    return malloc_(size);
}

int main(void) {
    print("main: calling dlsym\n");
    void *p = dlsym(RTLD_NEXT, "non_existing_symbol");
    if (!p) print("dlsym returned NULL\n");
    print("dlerror: ");
    print(dlerror());
    print("\n");
    return 0;
}

Expected results:
main: calling dlsym
dlsym returned NULL
dlerror: malloc called
malloc called
./malloc: undefined symbol: non_existing_symbol

Actual results:
main: calling dlsym
malloc called
dlsym returned NULL
dlerror: malloc called
malloc called
./malloc: undefined symbol: non_existing_symbol

Other considerations:
the dlopen/dlsym manuals do not (dis)allow malloc, but at least the FreeBSD
implementation[2] relies on statically allocated memory. For robustness maybe
it is not a bad idea to do the same (though this will limit error message
lengths).

-- 
You are receiving this mail because:
You are on the CC list for the bug.