libfuzzer fuzzing harness crash not reproducible

677 views Asked by At

I want to fuzz an existing harness from stbi harness and make a small change. From free(img) to if(img) free(img);

compile with this command clang -fsanitize=fuzzer,address -ggdb -O0 stbi_read_fuzzer.c -o fuzzer, and run with ./fuzzer corpus -fork=1 -ignore_crashes=1 -dict=jpeg.dict -seed=123

After few hours it produce some crash (global buffer overflow, heap use after free, buffer overflow). But when I run all crash file it didn't crash

aldo@vps:~/stb/tests$ ./fuzzer crash-edab9036233c269e258fe93c2a46d46d5d6e7112
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 2279336272
INFO: Loaded 1 modules   (2132 inline 8-bit counters): 2132 [0x61b510, 0x61bd64),
INFO: Loaded 1 PC tables (2132 PCs): 2132 [0x5d0258,0x5d8798),
./fuzzer: Running 1 inputs 1 time(s) each.
Running: crash-edab9036233c269e258fe93c2a46d46d5d6e7112
Executed crash-edab9036233c269e258fe93c2a46d46d5d6e7112 in 3 ms
***
*** NOTE: fuzzing was not performed, you have only
***       executed the target code on a fixed set of inputs.
***

Why it didn't crash? I'm using ubuntu 20.04 with llvm12 from apt.llvm.org

1

There are 1 answers

0
NikLeberg On

Old question but I had a similar issue.

In my case I fuzzed a stateful API and forgot to reset the API at the beginning of LLVMFuzzerTestOneInput. So a previous invocation set the API in a invalid state but it didn't crash right away. Only on second invocation the API did crash.

So my guess would be that similarly in your harness some internal state / global variable was changed in a previous invocation. Try to reset everything.

This is because libFuzzer runs in-process and just calls the LLVMFuzzerTestOneInput function as often as possible. The program won't get re-initialized on its own. This is documented:

  • The fuzzing engine will execute the fuzz target many times with different inputs in the same process.
  • Ideally, it should not modify any global state (although that’s not strict).