2.6 KiB
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 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 REPRODUCER_FILE
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 the Docker (how?, why?) commands to replicate the exact build steps used by OSS-Fuzz and then feed the reproducer input to the target.
-
Reproduce using the latest OSS-Fuzz build:
docker run --rm -v $testcase_file:/testcase -t ossfuzz/$target reproduce $fuzzer
It builds the fuzzer from the most recent successfull OSS-Fuzz build (roughly, last night's sources) and feeds the testcase file to the target function.
E.g. for the libxml2 fuzzer named libxml2_xml_read_memory_fuzzer it will be:
docker run --rm -ti -v ~/Downloads/testcase:/testcase ossfuzz/libxml2 reproduce libxml2_xml_read_memory_fuzzer
-
Reproduce using the local source code:
docker run --rm -v $target_checkout_dir:/src/$target
-v $reproducer_file:/testcase -t ossfuzz/$target reproduce $fuzzer
This is essentially the previous command that additionally mounts local sources into the running container.
- Fix the issue. Use the previous command to verify you fixed the issue locally. Use gdb if needed.
- Consider improving fuzzing support in your project's build and test system.
- Submit the fix. ClusterFuzz will automatically pick up the changes, recheck the testcase and will close the issue.