AddressSanitizer blacklist in c++ not working
Asked Answered
R

1

6

I'm trying to get address sanitizer blacklist working in a C++ project but its not working as expected. I tried the example on their website, if I compile with clang, it works fine.

build % cat suppress.txt
fun:bad_foo

build % cat foo.c
#include <stdlib.h>
void bad_foo() {
  int *a = (int*)malloc(40);
  a[10] = 1;
}
int main() { bad_foo(); }

build % clang -fsanitize=address -fsanitize-blacklist=suppress.txt foo.c ; ./a.out
Exit code: 0

But as soon as I use clang++, its ignored.

build % cp foo.c foo.cpp
build % clang++ -fsanitize=address -fsanitize-blacklist=suppress.txt foo.cpp ; ./a.out
=================================================================
==9943==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040000003f8 at pc 0x00010ff93ee8 bp 0x7ffedfc6c340 sp 0x7ffedfc6c338
WRITE of size 4 at 0x6040000003f8 thread T0
Provided dSYM: [/Users/.../build/./a.out.dSYM/Contents/Resources/DWARF/a.out] does not match symbol owner 0x7fe1b060edc0
    #0 0x10ff93ee7 in bad_foo() (a.out:x86_64+0x100000ee7)
    #1 0x10ff93f08 in main (a.out:x86_64+0x100000f08)
    #2 0x7fff7940508c in start (libdyld.dylib:x86_64+0x1708c)

0x6040000003f8 is located 0 bytes to the right of 40-byte region [0x6040000003d0,0x6040000003f8)
allocated by thread T0 here:
    #0 0x10fff2173 in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5c173)
    #1 0x10ff93e93 in bad_foo() (a.out:x86_64+0x100000e93)
    #2 0x10ff93f08 in main (a.out:x86_64+0x100000f08)
    #3 0x7fff7940508c in start (libdyld.dylib:x86_64+0x1708c)

SUMMARY: AddressSanitizer: heap-buffer-overflow (a.out:x86_64+0x100000ee7) in bad_foo()
Shadow bytes around the buggy address:
  0x1c0800000020: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 05
  0x1c0800000030: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 05
  0x1c0800000040: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 07
  0x1c0800000050: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x1c0800000060: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
=>0x1c0800000070: fa fa 00 00 00 00 00 05 fa fa 00 00 00 00 00[fa]
  0x1c0800000080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0800000090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c08000000a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c08000000b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c08000000c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==9943==ABORTING
[1]    9943 abort      ./a.out
Exit code: 134

I'm using clang-7 from releases.llvm.org

build % clang --version
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Users/.../clang+llvm-7.0.0-x86_64-apple-darwin/bin

Is this not supported under C++?

Radiolarian answered 30/11, 2018 at 0:16 Comment(1)
Not sure why, but I am able to use mangled (!) C++ function names in my suppression file with Clang 9.0. This only worked after I set ASAN_SYMBOLIZER_PATH correctly, which demangles the symbol names in the report. (This seems to be the case for you already. My current guess is that this is thanks to my newer version of ASan.)Wismar
C
5

In C++ function names will be mangled and it looks like the blacklist requires us to use mangled names, for example:

fun:_Z7bad_foov

then it will works for me. We can see form the example I think you are using they have an example of using a mangled name as well but they don't explain it:

# Turn off checks for a particular functions (use mangled names):
fun:MyFooBar
fun:_Z8MyFooBarv

You can use a utility like nm to find the mangled name, for example for your exmaple when I do:

nm a.out

I see something like this:

0000000100000e80 T __Z7bad_foov
...

Not sure why we obtain an extra _ but we do.

Culottes answered 30/11, 2018 at 5:8 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.