A scalable fuzzing infrastructure that is used for OSS-Fuzz backend. ClusterFuzz is also used to fuzz Chrome and many other projects. A quick overview of ClusterFuzz user interface is available on this page.
Or Fuzzer Build.
This refers to a build that contains all the fuzz targets for a given project, is run with a specific fuzzing engine, in a specific build mode (e.g. with enabled/disabled assertions), and optionally combined with a sanitizer.
A project is an open source software project that is integrated with OSS-Fuzz. Each project has a single set of configuration files (example: expat) and may have one or more fuzz targets (example: openssl).
Or a testcase.
A test input that causes a specific bug to reproduce.
Fuzzers are usually built with one or more sanitizer enabled.
$ python infra/helper.py build_fuzzers --sanitizer undefined json
| ||Address Sanitizer with Leak Sanitizer.|
| ||Undefined Behavior Sanitizer.|
| ||Memory Sanitizer. |
NOTE: It is critical that you build all the code in your program (including libraries it uses) with Memory Sanitizer. Otherwise, you will see false positive crashes due to an inability to see initializations in uninstrumented code.
| ||Used for generating code coverage reports. See Code Coverage doc.|
Compiler flag values for predefined configurations are specified in the Dockerfile. These flags can be overridden by specifying
You can choose which configurations to automatically run your fuzzers with in
project.yaml file (e.g. sqlite3).
ClusterFuzz supports fuzzing on x86_64 (aka x64) by default. However you can also fuzz using AddressSanitizer and libFuzzer on i386 (aka x86, or 32 bit) by specifiying the
$ARCHITECTURE build environment variable using the
python infra/helper.py build_fuzzers --architecture i386 json