Glossary

C

Crash state: A signature that we generate from the crash stacktrace for deduplication purposes.

Crash type: The type of crash. ClusterFuzz uses this to determine the severity. For security vulnerabilities, this may be (but not limited to): Bad-cast, Heap-buffer-overflow, Heap-double-free, Heap-use-after-free, Stack-buffer-overflow, Stack-use-after-return, Use-after-poison. Other crash types include: Null-dereference, Timeout, Out-of-memory, Stack-overflow, ASSERT.

Coverage: Some information about the behavior of the target when it executes a given input. Coverage is usually represented as the feature set that the input has triggered in the target.

Corpus: (also test corpus, or fuzzing corpus) (plural: corpora) A set of test inputs. In most contexts, it refers to a set of minimal test inputs that generate maximal code coverage.

Cross-pollination: The term is taken from botany, where one plant pollinates a plant of another variety. In fuzzing, cross-pollination means using a corpus for one fuzz target to expand a corpus for another fuzz target. For example, if there are two libraries that process the same common data format, it is often beneficial to cross-pollinate their respective corpora.

D

Distillation (creating a distilled corpus): A process of choosing a subset of a larger corpus, such that the subset has the same coverage features as the original corpus.

Dictionary: A file which specifies interesting tokens for a fuzz target. Most fuzzing engines support dictionaries, and will adjust their mutation strategies to process these tokens together.

F

Fuzz Target (also Target Function, or Fuzzing Target Function, or Fuzzing Entry Point): A binary, a library, an API, or rather anything that can consume bytes for input and produce some sort of coverage data as an output. 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. Read more about good fuzzing target here.

Fuzzer: The most overloaded term and used in a variety of contexts, which makes it bad. Sometimes, "Fuzzer" is referred to a fuzz target, a fuzzing engine, a mutation engine, a test generator or a fuzzer build.

Fuzz Input: A sequence of bytes that can be fed to a target. The input can be an arbitrary bag of bytes, or some structured data, e.g. serialized proto.

Fuzz Feature: A number that represents some unique behavior of the target. E.g. a feature 1234567 may represent the fact that a basic block number 987 in the target has been executed 7 times. When executing an input with the target, the fuzzer collects the features that were observed during execution.

Fuzz Feature Set: A set of features associated with one specific input.

Fuzzer Build: A build that contains all the fuzz targets for a given project, which is run with a specific fuzzing engine, in a specific build mode (e.g. with enabled/disabled assertions), and optionally combined with a sanitizer.

Fuzzing Engine: A program that produces an infinite stream of inputs for a fuzz target and orchestrates the execution. Examples: libFuzzer, AFL, honggfuzz, etc. See related terms Mutation Engine and Test Generator.

M

Mutation Engine: A tool that takes a set of testcases as input and creates their mutated versions. It is just a generator and does not feed the mutations to fuzz target. Example: radamsa (a generic test mutator).

Mutator: A function that takes bytes as input and outputs a small random mutation of the input. See also: structure-aware fuzzing.

Minimization: A process that tries to minimize a testcase to its smallest possible size, such that it still triggers the same underlying bug on the target program.

R

Reliability of reproduction: A crash is reliably reproducible if the target program consistently crashes with the same crash state for the given input.

Reproducer: (also Test Case): A test input that can be used to reproduce a bug when processed by a fuzz target.

S

Shard: A file representing a subset of the corpus and another file representing feature sets for that same subset of the corpus.

Sanitizer: A dynamic testing tool that can detect bugs during program execution. Examples: ASan, DFSan, LSan, MSan, TSan, UBSan. See also: https://github.com/google/sanitizers

Seed Corpus: A small initial corpus prepared with the intent of providing initial coverage for fuzzing. Rather than being created by the fuzzers themselves, seed corpora are often prepared from existing test inputs or may be hand-crafted to provide interesting coverage. They are often checked into source alongside fuzz targets.

T

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.

Test Generator: A tool that generates testcases from scratch according to some rules or grammar. Examples: csmith (a test generator for C language), cross_fuzz (a cross-document DOM binding test generator).

Test Input: A sequence of bytes that is used as input to a fuzz target. Typically, a test input is stored in a separate file.