Skip to content

Latest commit

 

History

History
59 lines (45 loc) · 3.06 KB

reproducing.md

File metadata and controls

59 lines (45 loc) · 3.06 KB
Raw

Reproducing OSS-Fuzz issues

You've been CC'ed on an OSS-Fuzz issue (examples), now what? Before attempting to fix the bug, you should be able to reliably reproduce it.

Every issue has a reproducer (aka "testcase") file attached. Download it. If the issue is not public, you will need to login using your Google account (why?) that the bug report CCs. This file contains the bytes that were fed to the Fuzz Target.

If you have already integrated the fuzz target with your build and test system, all you do is run:

$ ./fuzz_target_binary <testcase_path>

If this is a timeout bug, add the -timeout=25 argument.
If this is an OOM bug, add the -rss_limit_mb=2048 argument.
Read more on how timeouts and OOMs are handed here.

Depending on the nature of the bug, the fuzz target binary needs to be built with the appropriate sanitizer (e.g. if this is a buffer overflow, with AddressSanitizer).

If you are not sure how to build the fuzzer using the project's build system, you may also use Docker (how?, why?) commands to replicate the exact build steps used by OSS-Fuzz and then feed the reproducer input to the fuzz target.

  • Reproduce using latest OSS-Fuzz build:
$ python infra/helper.py build_fuzzers $PROJECT_NAME
$ python infra/helper.py reproduce $PROJECT_NAME <fuzz_target_name> <testcase_path>

It builds the fuzzer from the most recent successful OSS-Fuzz build (usually last night's sources) and feeds the testcase file to the target function.

E.g. for libxml2 project with fuzzer named libxml2_xml_read_memory_fuzzer, it will be:

$ python infra/helper.py build_fuzzers libxml2
$ python infra/helper.py reproduce libxml2 libxml2_xml_read_memory_fuzzer ~/Downloads/testcase
  • Reproduce using local source checkout:
$ python infra/helper.py build_fuzzers $PROJECT_NAME <source_path>
$ python infra/helper.py reproduce $PROJECT_NAME <fuzz_target_name> <testcase_path>

This is essentially the previous command that additionally mounts local sources into the running container.

  • Fix issue. Write a patch to fix the issue in your local checkout and then use the previous command to verify the fix (i.e. no crash occurred). Use gdb if needed.
  • Submit fix. Submit the fix in the project's repository. ClusterFuzz will automatically pick up the changes, recheck the testcase and will close the issue (in < 1 day).
  • Improve fuzzing support. Consider improving fuzzing support in your project's build and test system.