This page provides a glossary of what certain terms mean in the context of ClusterFuzz.
A machine which runs ClusterFuzz tasks.
A set of inputs for a fuzz target. In most contexts, it refers to a set of minimal test inputs that generate maximal code coverage.
A task which takes a corpus and removes unnecessary inputs while maintaining the same code coverage.
A signature that we generate from the crash stacktrace for deduplication purposes.
The type of a crash. ClusterFuzz uses this to determine the severity.
For security vulnerabilities this may be (but not limited to):
Other crash types include:
A function or program that accepts an array of bytes and does something interesting with these bytes using the API under test. See the libFuzzer documentation for a more detailed explanation. A fuzz target is typically given the array of bytes by libFuzzer or AFL for coverage guided fuzzing.
A tool used for performing coverage guided fuzzing. The fuzzing engine typically mutates inputs, gets coverage information, and adds inputs to the corpus based on new coverage information. ClusterFuzz supports the fuzzing engines libFuzzer and AFL. See our guide on setting up libFuzzer and AFL for more details.
A specification for how to run a particular target program for fuzzing, and where the builds are located. Consists of environment variable values.
A task that tries to minimize a testcase to its smallest possible size, such that it still triggers the same underlying bug on the target program.
Reliability of reproduction
A crash is reliably reproducible if the target program consistently crashes with the same crash state for the given input.
A range of commits in which the bug was originally introduced. It is of the form
A number (not a git hash) that can be used to identify a particular build. This number should increment with every source code revision. For SVN, this can be just the SVN source code revision. For Git, you need to create an equivalent mapping from numbers to git hashes. The mapping number can be an id that starts at
1 and is incremented or can be a date format (e.g.
A dynamic testing tool that uses compile-time instrumentation to detect bugs during program execution. Examples:
- ASan (aka AddressSanitizer)
- LSan (aka LeakSanitizer)
- MSan (aka MemorySanitizer)
- UBSan (aka UndefinedBehaviorSanitizer)
- TSan (aka ThreadSanitizer)
Sanitizers are best supported by the Clang compiler. ASan, or AddressSanitizer, is usually the most important sanitizer as it reveals the most memory corruption bugs.
A unit of work to be performed by a bot, such as a fuzzing session or minimizing a testcase.
An input for the target program that causes a crash or bug. On a testcase details page, you can download a “Minimized Testcase” or “Unminimized Testcase”, these refer to the input that needs to be passed to the target program.