regexec() interception broken on Ubuntu GLIBC 2.27

[arichardson]

I was trying to use ASan to instrument a program that uses the REG_STARTSTOP flag for regexec.
This resulted in an inifite loop since this flag was being ignore. After lots of debugging I noticed that ASan instrumentation resulted in GLibc's __compat_regexec being called instead of __regexec.
The difference between those functions is that __compat_regexec strips the REG_STARTSTOP flag (https://code.woboq.org/userspace/glibc/posix/regexec.c.html#239).

I don't quite understand why dlsym gives the compat (the @GLIBC_2.2.5 version) symbol instead of the newer one (@GLIBC_2.3.4).
A small test program shows that resolving it using RTLD_DEFAULT finds the 2.3.4 version but RTLD_NEXT find 2.2.5:

#define _GNU_SOURCE

#include <regex.h>
#include <dlfcn.h>
#include <stdio.h>


__asm__(".symver __compat_regexec, regexec@GLIBC_2.2.5");
__asm__(".symver __regexec, regexec@GLIBC_2.3.4");
void __compat_regexec(void);
void __regexec(void);

int main() {
    printf("addrof regexec=%p\n", &regexec);
    printf("addrof __regexec=%p\n", &__regexec);
    printf("addrof __compat_regexec=%p\n", &__compat_regexec);
    printf("dlsym(RTLD_NEXT, regexec)=%p\n", dlsym(RTLD_NEXT, "regexec"));
    printf("dlsym(RTLD_DEFAULT, regexec)=%p\n", dlsym(RTLD_DEFAULT,"regexec"));
    printf("dlvsym(RTLD_NEXT, regexec@GLIBC_2.3.4)=%p\n", dlvsym(RTLD_NEXT, "regexec", "GLIBC_2.3.4"));
    printf("dlvsym(RTLD_DEFAULT, regexec@GLIBC_2.3.4)=%p\n", dlvsym(RTLD_DEFAULT, "regexec", "GLIBC_2.3.4"));
    printf("dlvsym(RTLD_NEXT, regexec@GLIBC_2.2.5)=%p\n", dlvsym(RTLD_NEXT, "regexec", "GLIBC_2.2.5"));
    printf("dlvsym(RTLD_DEFAULT, regexec@GLIBC_2.2.5)=%p\n", dlvsym(RTLD_DEFAULT, "regexec", "GLIBC_2.2.5"));
}

The output of this program on Ubuntu 18.04 is:

addrof regexec=0x7f3458cf8700
addrof __regexec=0x7f3458cf8700
addrof __compat_regexec=0x7f3458d5e540
dlsym(RTLD_NEXT, regexec)=0x7f3458d5e540
dlsym(RTLD_DEFAULT, regexec)=0x7f3458cf8700
dlvsym(RTLD_NEXT, regexec@GLIBC_2.3.4)=0x7f3458cf8700
dlvsym(RTLD_DEFAULT, regexec@GLIBC_2.3.4)=0x7f3458cf8700
dlvsym(RTLD_NEXT, regexec@GLIBC_2.2.5)=0x7f3458d5e540
dlvsym(RTLD_DEFAULT, regexec@GLIBC_2.2.5)=0x7f3458d5e540

I can see there is already a workaround fo realpath (llvm/llvm-project@77ef78a), maybe this needs a similar workaround (or we use dlvsym to resolve this symbol)?

Maybe it's sufficient to change
COMMON_INTERCEPT_FUNCTION(regexec);
to COMMON_INTERCEPT_FUNCTION_VER(regexec, "GLIBC_2.3.4"); if SANITIZER_GLIBC is defined?

[arichardson]

https://reviews.llvm.org/D96348 fixes this.

[arichardson]

Fixed in llvm/llvm-project@ad294e5