From Florian Weimer's D144073
On GNU/Linux (glibc), the crypt and crypt_r functions are not part of the main shared object (libc.so.6), but libcrypt (with multiple possible sonames). The sanitizer libraries do not depend on libcrypt, so it can happen that during sanitizer library initialization, no real implementation will be found because the crypt, crypt_r functions are not present in the process image (yet). If its interceptors are called nevertheless, this results in a call through a null pointer when the sanitizer library attempts to forward the call to the real implementation.
Many distributions have already switched to libxcrypt, a library that is separate from glibc and that can be build with sanitizers directly (avoiding the need for interceptors). This patch disables building the interceptor for glibc targets.
Let's remove crypt and crypt_r interceptors (D68431) to fix issues with
For older glibc, msan will not know that an uninstrumented crypt_r call
initializes data, so there is a risk for false positives. However, with some
codebase survey, I think crypt_r uses are very few and the call sites typically
have a memset(&data, 0, sizeof(data)); anyway.