2016-11-16 17:56:10 +00:00
|
|
|
# Reproducing OSS-Fuzz issues
|
2016-10-26 16:40:37 +00:00
|
|
|
|
2016-11-19 01:20:49 +00:00
|
|
|
You've been CC'ed on an OSS-Fuzz issue
|
|
|
|
|
([examples](https://bugs.chromium.org/p/oss-fuzz/issues/list)), now what?
|
2016-11-19 01:18:02 +00:00
|
|
|
Before attempting a fix the bug you should be able to reliably reproduce it.
|
2016-10-27 03:48:30 +00:00
|
|
|
|
2016-11-19 01:18:02 +00:00
|
|
|
Every issue has a reproducer file attached.
|
2016-11-19 01:20:49 +00:00
|
|
|
Download it. If the issue is not public, you will need to login using your Google account
|
|
|
|
|
that is CC-ed to the bug report.
|
2016-11-19 01:18:02 +00:00
|
|
|
This file contains the bytes that were fed to the [Fuzz Target](http://libfuzzer.info/#fuzz-target).
|
|
|
|
|
|
|
|
|
|
If you have [properly integrated](ideal_integration.md) the fuzz target with your build and test system
|
2016-11-19 01:21:07 +00:00
|
|
|
all you is to run
|
2016-11-19 01:18:02 +00:00
|
|
|
```
|
|
|
|
|
./fuzz_target_binary REPRODUCER_FILE
|
|
|
|
|
```
|
2016-11-19 01:20:49 +00:00
|
|
|
Depending on the nature of the bug, the fuzz target binary needs to be built with the appropriate sanitizer
|
2016-11-19 01:18:02 +00:00
|
|
|
(e.g. if this is a buffer overflow, with [AddressSanitizer](http://clang.llvm.org/docs/AddressSanitizer.html)).
|
|
|
|
|
|
2016-11-21 21:15:50 +00:00
|
|
|
If you are not sure how to build fuzzers within the target, you may also use
|
|
|
|
|
Docker (([how?](installing_docker.md), [why?](faq.md#why-do-you-use-docker))) commands
|
|
|
|
|
to replicate the exact build steps used by OSS-Fuzz and then feed the reproducer input to the target.
|
2016-10-26 16:40:37 +00:00
|
|
|
|
2016-10-27 03:46:20 +00:00
|
|
|
- *Reproduce from nightly sources:*
|
2016-10-26 18:04:46 +00:00
|
|
|
|
2016-10-26 21:59:27 +00:00
|
|
|
<pre>
|
2016-10-27 03:41:40 +00:00
|
|
|
docker run --rm -v <b><i>$testcase_file</i></b>:/testcase -t ossfuzz/<b><i>$target</i></b> reproduce <b><i>$fuzzer</i></b>
|
2016-10-26 21:59:27 +00:00
|
|
|
</pre>
|
2016-10-26 18:04:46 +00:00
|
|
|
|
2016-10-26 18:51:01 +00:00
|
|
|
It builds the fuzzer from nightly sources (in the image) and runs it with testcase input.
|
2016-10-26 21:13:17 +00:00
|
|
|
E.g. for libxml2 it will be:
|
|
|
|
|
|
2016-10-26 22:10:58 +00:00
|
|
|
<pre>
|
2016-10-27 03:40:55 +00:00
|
|
|
docker run --rm -ti -v <b><i>~/Downloads/testcase</i></b>:/testcase ossfuzz/<b><i>libxml2</i></b> reproduce <b><i>libxml2_xml_read_memory_fuzzer</i></b>
|
2016-10-26 22:10:58 +00:00
|
|
|
</pre>
|
2016-10-27 03:46:20 +00:00
|
|
|
- *Reproduce from local sources:*
|
2016-10-26 18:04:46 +00:00
|
|
|
|
2016-10-27 03:40:55 +00:00
|
|
|
<pre>
|
2016-10-27 03:44:11 +00:00
|
|
|
docker run --rm -v <b><i>$target_checkout_dir</i></b>:/src/<b><i>$target</i></b> \
|
|
|
|
|
-v <b><i>$reproducer_file</i></b>:/testcase -t ossfuzz/<b><i>$target</i></b> reproduce <b><i>$fuzzer</i></b>
|
2016-10-27 03:40:55 +00:00
|
|
|
</pre>
|
2016-10-26 18:04:46 +00:00
|
|
|
|
2016-11-19 02:54:10 +00:00
|
|
|
This is essentially the previous command that additionally mounts local sources into the running container.
|
2016-11-02 19:43:54 +00:00
|
|
|
- *Fix the issue.* Use the previous command to verify you fixed the issue locally.
|
|
|
|
|
[Use gdb](debugging.md#debugging-fuzzers-with-gdb) if needed.
|
2016-10-27 03:45:52 +00:00
|
|
|
- *Submit the fix.* ClusterFuzz will automatically pick up the changes, recheck the testcase
|
2016-10-26 18:04:46 +00:00
|
|
|
and will close the issue.
|
