-fsanitize=fuzzer is not handling exceptions correctly

[jonathanmetzman]

The only case I've verified where this happens is jsonnet.
However, it looks like the same issue occurs with freeimage (load_from_memory_fuzzer), libsass (data_context_fuzzer), and opencv (imdecode_fuzzer)

To reproduce, download my patch and run these commands:

git apply jsonnet.txt
python infra/helper.py build_fuzzers jsonnet
python infra/helper.py check_build jsonnet
...
AddressSanitizer:DEADLYSIGNAL
=================================================================
==36==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f236d5b6d10 bp 0x00000090605b sp 0x7ffd7f950d68 T0)
==36==The signal is caused by a READ memory access.
==36==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
ERROR: 100% of fuzz targets seem to be broken. See the list above for a detailed information.
Check build failed

This is a stacktrace that I captured slightly before the crash occurs.

#0  __asan_handle_no_return () at /src/llvm/projects/compiler-rt/lib/asan/asan_rtl.cc:598
#1  0x00000000005f7084 in (anonymous namespace)::Parser::parseTerminalBracketsOrUnary (this=0x6110000000c0) at /src/jsonnet/core/parser.cpp:591
#2  0x00000000005e5321 in (anonymous namespace)::Parser::parse (this=0x7fffffffcec0, max_precedence=<optimized out>) at /src/jsonnet/core/parser.cpp:898
#3  0x00000000005e49f8 in jsonnet_parse (alloc=<optimized out>, tokens=...) at /src/jsonnet/core/parser.cpp:1093
#4  0x00000000005caed7 in jsonnet_evaluate_snippet_aux (vm=<optimized out>, filename=<optimized out>, snippet=<optimized out>, error=<optimized out>, kind=<optimized out>) at /src/jsonnet/core/libjsonnet.cpp:492
#5  0x00000000005ca76d in jsonnet_evaluate_snippet (vm=0x60f000000040, filename=0x89c900 <.str> "", snippet=0x7fffffffdaa1 "", error=0x7fffffffd9c0) at /src/jsonnet/core/libjsonnet.cpp:667
#6  0x00000000005bbcce in ConvertJsonnetToJson(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) () at convert_jsonnet_fuzzer.cc:24
#7  0x00000000005bc011 in LLVMFuzzerTestOneInput () at convert_jsonnet_fuzzer.cc:40
#8  0x00000000004c2f35 in ExecuteCallback () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:529
#9  0x00000000004c4e54 in ReadAndExecuteSeedCorpora () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:729
#10 0x00000000004c5426 in Loop () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:779
#11 0x00000000004b437b in FuzzerDriver () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:776
#12 0x00000000004de3d3 in main () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19

The crash does not occur when -lFuzzingEngine is used instead of -fsanitize=fuzzer

The source line (parser.cpp:591) causing the crash contains:
throw StaticError(tok.location, "unexpected end of file.");

I think this crash has something to do with exceptions.

[jonathanmetzman]

cc @morehouse @kcc

[jonathanmetzman]

This happens with and without ASAN

[jonathanmetzman]

Actually I think the real top two frames are:

#0  0x00007ffff729f1f0 in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#1  0x00000000006ade17 in __cxa_throw ()

and not __asan_handle_no_return

All of the projects I mentioned above use exceptions btw
https://github.com/opencv/opencv/search?q=throw&unscoped_q=throw
https://github.com/sass/libsass/search?q=throw&unscoped_q=throw
https://github.com/imazen/freeimage/search?q=throw&unscoped_q=throw

[jonathanmetzman]

I have a small reproducer on host (without oss-fuzz). But I'm not sure it reveals the exact problem.

Steps:
Download my fuzz target source:
fuzzer.txt

Then run these commands:

CC=$HOME/path/to/fresh/clang CXX=$HOME/path/to/fresh/clang++ cmake -DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON -DLIBCXXABI_ENABLE_SHARED=OFF -DLLVM_TARGETS_TO_BUILD="X86" -G "Ninja" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="compiler-rt;clang;libcxx;libcxxabi" ../llvm
ninja
mv fuzzer.txt fuzzer.cc
./bin/clang++ -fsanitize=fuzzer fuzzer.cc -stdlib=libc++ -o fuzzer
./fuzzer
terminating with uncaught exception of type char const*
==164295== ERROR: libFuzzer: deadly signal
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==164295==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb2d3d294d8 bp 0x7ffff6fa6890 sp 0x7ffff6fa6720 T164295)
==164295==The signal is caused by a READ memory access.
==164295==Hint: address points to the zero page.
Segmentation fault

It seems like libFuzzer shouldn't be crashing when bubbling up an exception which is what appears to be happening in this case.

I'm not sure this reproducer is accurate though since the fuzz target will run when compiled with -lFuzzingEngine, it doesn't quit because of an uncaught exception, but in this case catching const char* causes the problem to go away.

I'll keep poking around and will try to come up with something better.

[kcc]

guess: we may need to remove -fno-exceptions from the build flags.
(though I don't understand why)

[jonathanmetzman]

From libFuzzer's build?

[kcc]

scratch that. The example from #2328 (comment) throws exception of one type and catches an exception of another type, i.e. the exception goes undetected into libFuzzer, which causes it to abort with an error message. I think it's a valid behavior. No?

[jonathanmetzman]

I think you're correct, my reproducer is no good. But i think there's still a legitimate issue here

[jonathanmetzman]

Actually, the stacktrace in my example isn't exactly what I expect:

==164295== ERROR: libFuzzer: deadly signal
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==164295==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb2d3d294d8 bp 0x7ffff6fa6890 sp 0x7ffff6fa6720 T164295)
==164295==The signal is caused by a READ memory access.
==164295==Hint: address points to the zero page.
Segmentation fault

It almost looks like two error handlers are being invoked?

If one compiles the same testcase without -stdlib=libc++ the stacktrace is actually what one expects:

./fuzzer
INFO: Seed: 507092804
INFO: Loaded 1 modules   (8 inline 8-bit counters): 8 [0x708080, 0x708088), 
INFO: Loaded 1 PC tables (8 PCs): 8 [0x4de148,0x4de1c8), 
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
terminate called after throwing an instance of 'char const*'
==252857== ERROR: libFuzzer: deadly signal
    #0 0x4c50d0  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x4c50d0)
    #1 0x427a38  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x427a38)
    #2 0x414723  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x414723)
    #3 0x7fad0ae230bf  (/lib/x86_64-linux-gnu/libpthread.so.0+0x110bf)
    #4 0x7fad0a481fce  (/lib/x86_64-linux-gnu/libc.so.6+0x32fce)
    #5 0x7fad0a4833f9  (/lib/x86_64-linux-gnu/libc.so.6+0x343f9)
    #6 0x7fad0b3bf826  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x8c826)
    #7 0x7fad0b3c5a39  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x92a39)
    #8 0x7fad0b3c5a94  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x92a94)
    #9 0x7fad0b3c5ce7  (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x92ce7)
    #10 0x4c64f7  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x4c64f7)
    #11 0x415b50  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x415b50)
    #12 0x41735d  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x41735d)
    #13 0x4179c5  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x4179c5)
    #14 0x40dd8a  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x40dd8a)
    #15 0x428182  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x428182)
    #16 0x7fad0a46f2b0  (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
    #17 0x407959  (/usr/local/google/home/metzman/llvm-project/build/fuzzer+0x407959)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 0 ; base unit: 0000000000000000000000000000000000000000


artifact_prefix='./'; Test unit written to ./crash-da39a3ee5e6b4b0d3255bfef95601890afd8070

I don't know if these issues are related at all though so maybe this is totally unrelated.

[kcc]

I'd say this is something else. Handling uncaught exceptions is probably not that urgent.