bbdccf4c94
In terms of bug catching capability, `_FORTIFY_SOURCE` does not perform as well as some dynamic instrumentation tools. When a sanitizer is used, generally `_FORTIFY_SOURCE` should be disabled since sanitizer runtime does not implement most `*_chk` functions. Using `_FORTIFY_SOURCE` will regress error checking (asan/hwasan/tsan) or cause false positives (msan). `*printf_chk` are the most pronounced `_chk` interceptors for uninstrumented DSOes (https://reviews.llvm.org/D40951). glibc 2.40 introduced `pass_object_info` style fortified source for some functions ([1]). `fprintf` will be mangled as `_ZL7fprintfP8_IO_FILEU17pass_object_size1PKcz`, which has no associated interceptor, leading to printf-fortify-5.c failure. Just disable the test. Fix #100877 [1]: https://sourceware.org/pipermail/libc-alpha/2024-February/154531.html Pull Request: https://github.com/llvm/llvm-project/pull/101566
20 lines
592 B
C
20 lines
592 B
C
// RUN: %clang -fPIC -shared -O2 -D_FORTIFY_SOURCE=2 -D_DSO %s -o %t.so
|
|
// RUN: %clang_asan -o %t %t.so %s
|
|
// RUN: not %run %t 2>&1 | FileCheck %s
|
|
/// Incompatible with pass_object_info style fortified source since glibc 2.40.
|
|
// REQUIRES: glibc-2.27 && !glibc-2.40
|
|
#ifdef _DSO
|
|
#include <stdio.h>
|
|
#include <stdlib.h>
|
|
#include <string.h>
|
|
__attribute__((noinline)) int foo() {
|
|
char *read_buffer = (char *)malloc(1);
|
|
// CHECK: AddressSanitizer: heap-buffer-overflow
|
|
fprintf(stderr, read_buffer, 4096);
|
|
return read_buffer[0];
|
|
}
|
|
#else
|
|
extern int foo();
|
|
int main() { return foo(); }
|
|
#endif
|