Why is libFuzzer on Windows yielding error: "no interesting inputs were found"?

Question

About half a year ago I had setup a CMake project with VSCode with a libFuzzer target that ran on Windows and macOS. I use the C++ extension along with the CMakeTools extension from Microsoft.

When I resumed the project again now I'm getting an error at the end of the run of the fuzzer:

ERROR: no interesting inputs were found. Is the code instrumented for coverage? Exiting.

Full output:

INFO: Seed: 2201882200
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: A corpus is not provided, starting from an empty corpus
#2      INITED exec/s: 0 rss: 61Mb
ERROR: no interesting inputs were found. Is the code instrumented for coverage? Exiting.

Compared to the same fuzzer when it's run on macOS:

INFO: Seed: 1824512455
INFO: Loaded 1 modules   (7 inline 8-bit counters): 7 [0x10c2baa88, 0x10c2baa8f), 
INFO: Loaded 1 PC tables (7 PCs): 7 [0x10c2baa90,0x10c2bab00), 
INFO:        6 files found in /Users/thomas/SourceTree/vscode-cmake-libfuzzer/fuzzers/corpus/fuzz_test/
INFO: seed corpus: files: 6 min: 1b max: 10b total: 37b rss: 30Mb
#7      INITED cov: 1 ft: 1 corp: 1/1b exec/s: 0 rss: 30Mb
#1048576        pulse  cov: 1 ft: 1 corp: 1/1b lim: 8192 exec/s: 524288 rss: 1099Mb
#2097152        pulse  cov: 1 ft: 1 corp: 1/1b lim: 8192 exec/s: 699050 rss: 1100Mb
#4194304        pulse  cov: 1 ft: 1 corp: 1/1b lim: 8192 exec/s: 599186 rss: 1101Mb
#5740032        DONE   cov: 1 ft: 1 corp: 1/1b lim: 8192 exec/s: 521821 rss: 1101Mb
Done 5740032 runs in 11 second(s)
stat::number_of_executed_units: 5740032
stat::average_exec_per_sec:     521821
stat::new_units_added:          0
stat::slowest_unit_time_sec:    0
stat::peak_rss_mb:              1101

Snippets of how I linked libFuzzer: (I added the libs to Windows manually as one must to make it link.)

  # https://llvm.org/docs/LibFuzzer.html#fuzzer-usage
  target_link_libraries(clang_fuzzer INTERFACE
    -fsanitize=fuzzer,address
  )
  target_compile_options(clang_fuzzer INTERFACE
    -fsanitize=fuzzer,address
  )

The test fuzzer:

#include <iostream>
#include <stddef.h>
#include <stdint.h>

bool FuzzMe(const uint8_t *Data, size_t DataSize) {
  return DataSize >= 3 &&
      Data[0] == 'F' &&
      Data[1] == 'U' &&
      Data[2] == 'Z' &&
      Data[3] == 'Z';  // :‑<
}

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
{
  // std::cout << "Hello Fuzzy...\n";
  FuzzMe(data, size);
  return 0;
}

Minimal complete example: https://github.com/thomthom/vscode-cmake-libfuzzer

On Windows I had installed clang via the snapshots made available: https://llvm.org/builds/

On macOS I installed it via brew install llvm (Since AppleClang doesn't include libFuzzer)

I've tested this on two Windows machines now that both used to run the fuzzer fine, now they don't. But I've not able to figure out what caused the regression. I know I didn't update Clang on either systems. On one I also tried installing Clang via Visual Studio, and I tried selecting that installation as well from VSCode to see if it made any difference, but no avail.

Only other thing I can think of is that my VSCode CMake projects needed adjustments after the VSCode-Tools extension updated the default generator for Windows. I don't recall what it used to use. I still find it strange if that should affect the libFuzzer.

score 0 · Answer 1 · answered Mar 09 '21 at 16:03

It turned out to be caused by my CMake config omitting these lines for Windows builds:

  target_link_libraries(clang_fuzzer INTERFACE
    -fsanitize=fuzzer,address
  )

I think some cache came into play here that caused me not to detect this when I did the initial work on this.

Commit for fix in my above example:

https://github.com/thomthom/vscode-cmake-libfuzzer/commit/d7553fe01f88c71c19ff8f833b4235b8a3d17f99

score 0 · Answer 2 · answered Dec 18 '22 at 10:27

Hoping that it can be useful for some people, I am posting my experience with this error.

In my case, I was getting this error merely because I changed the permission of the corpus folder (see the command below). The reason I was doing it because libfuzzer was not adding new inputs to the corpus folder.

chmod 644 /corpus (this command caused the error)

To avoid this error, I tried another method to be able to add new inputs to the folder; changed the owner of corpus folder to the user of the fuzzer process (i.e., daemon in my case).

mkdir /corpus;chown daemon:daemon /corpus (this command helped)

Why is libFuzzer on Windows yielding error: "no interesting inputs were found"?

2 Answers2