Hello, I am trying to use address sanitizer when compiling from llvm bitcode and I came across this, but it only partially solved my issue. The final binary has address sanitizer but isn’t able to catch heap buffer overflows. Is anyone familiar with the sanitizer passes in llvm and know how I can replicate them when compiling from bitcode?
Trying to ASan-ify bitcode is definitely an unsupported path.
There are various things that could go wrong that could cause your specific case. Here’s what I’d check first:
- Are you linking the ASan runtime and this getting ASan-ified mallocs()? You can check by looking for the
asan_mallocsymbol:llvm-readelf -a $bin | grep asan_malloc. You should see something like _ZN6__asan11asan_mallocEmPN11__sanitizer18BufferedStackTraceE assuming you’re using a relatively modern version of clang. - Check for asan-looking checks in the disassembly of the function where you expect the buffer overflow to happen.
On Wed, 14 Feb 2024 at 08:01, Tanapoom S via LLVM Discussion Forums <notifications@llvm.discoursemail.com> wrote:
timidpigeon
February 14Hello, I am trying to use address sanitizer when compiling from llvm bitcode and I came across this, but it only partially solved my issue. The final binary has address sanitizer but isn’t able to catch heap buffer overflows. Is anyone familiar with the sanitizer passes in llvm and know how I can replicate them when compiling from bitcode?
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
Try clang -fsanitize=address -O0 -g -emit-llvm -c main.c -o main.bc
Thanks for the tip. I checked for the symbols, and the ASAN runtime is linked, but did not find any asan_malloc symbol, so it seems the mallocs aren’t instrumented properly. This narrows down my search quite a bit. Do you know if it’s possible to do these instrumentation manually or force llvm to do them when generating the bitcode somehow?
ASAN runtime is linked, but did not find any asan_malloc symbol
How are you determining that the ASan runtime is linked. The “grep for asan_malloc” is supposed to check “did you link the runtime”, unless you’re using dynamic linkage (which is uncommon, Android only IIRC).
You won’t see calls to asan_malloc in ASan-instrumented code (if that’s what you’re looking for). The way we take over malloc() is by ELF symbol interposition.
I’m assuming you know the offending malloc, and the offending overflow. You can try using __asan_describe_address(ptr) at those two spots to figure out whether the address is properly ASan-ified (whether it’s the callsite or the malloc that’s the problem).
I believe it is dynamically linked since I compile with -lasan. Compiling with -fsanitize=address shows asan_malloc in the elf symbols but causes the binary to crash with SEGV even on non overflowing inputs.
Checking the disassembly helped me narrow the issue down to one of our custom instrumentation passes. Thank you very much for your help!