Skip to main content

Glossary

Collection of terms and definitions commonly encountered in fuzzing.

Fuzzer/fuzzing engine​

A piece of software that generates input to feed into the system under test (SUT) via the fuzz tests. A coverage-guided fuzzer also leverages instrumentation to gather rich runtime signals including code coverage during the execution and optimize test case generation to maximize code coverage.

Fuzz test/fuzz target​

A test harness that invokes the system under test with fuzzer-generated input. Usually, it's a function that takes fuzzer-generated inputs as arguments, for example a byte buffer with corresponding size for libFuzzer targets, and calls functions from the system under test.

Fuzzing​

Fuzzing is the act of executing a fuzz test against a SUT with a fuzzing engine. A fuzzing engine generates arbitrary inputs and feeds them to the SUT via the fuzz test. It then observes the behavior of the SUT for each input to detect unexpected or undesired results such as crashes.

Corpus​

A saved set of inputs that a fuzz test uses to trigger execution of code paths in the SUT.

Seed corpus​

A small corpus that's usually provided by the user. A seed corpus aids the fuzzing engine in quickly reaching new code paths in the SUT. The fuzzing engine mutates these initial seeds to discover more novel code paths.

See the libFuzzer documentation on corpora for more information.

Generated corpus​

The generated corpus is a set of inputs that triggered unique code paths during fuzzing. The fuzzing engine saves this corpus which it utilizes in subsequent fuzzing runs.

Replayer​

A replayer runs a fuzz test using only inputs saved from previously triggered Findings. This differs from a normal fuzzing run because the fuzzing engine doesn't generate new inputs or use the standard corpus as a source of inputs. This can be useful for debugging fuzz tests and performing regression testing for previously identified Findings.

Sanitizer​

Sanitizers are tools that add instrumentation to the SUT by being linked to the SUT at compile time. The instrumentation acts as run-time bug detector for issues such as buffer overflow, signed integer overflow, uninitialized memory read and other bugs.

See the google documentation on sanitizers for more information.

Finding​

A Finding describes a bug or vulnerability found by the fuzzer. CI Fuzz provides details on the bug type and includes the input that triggered it and the generated stack trace.

Coverage​

Coverage describes the code reached and executed during an application/fuzzing run. It's measured in different categories, for example lines, functions, or branches.