Coverage-based Greybox Fuzzing

Technique

Coverage-based greybox fuzzing is a fuzzing methodology that uses runtime coverage feedback to guide input generation. It is described in recent literature as a dominant vulnerability-discovery methodology and has been adapted beyond conventional software targets to structured-input parsers, multi-component OS/firmware systems, and hardware/processor fuzzing.

First seen 5/28/2026

Last seen 6/8/2026

Evidence 7 chunks

Wiki v1

WIKI

Overview

Coverage-based greybox fuzzing (CGF) is a fuzzing methodology that uses runtime coverage information as feedback for generating and selecting test inputs. Public literature describes it as a dominant methodology for vulnerability discovery, widely applied to application software as well as system software such as kernels and firmware. It is also the basis for specialized variants such as grammar-aware fuzzing for structured inputs, multi-target fuzzing across cooperating software components, and hardware fuzzing of RTL designs.

Core feedback loop

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

5 connections

ProcessorFuzz ← implements 95% 6e

ProcessorFuzz implements coverage-based greybox fuzzing adapted for hardware processors.

DiFuzzRTL ← implements 100% 5e

DIFUZZRTL adapts CGF to capture FSM state transitions during RTL simulation.

hardware fuzzing ← uses 90% 2e

Hardware fuzzing adapts Coverage-based Greybox Fuzzing for processor RTL verification.

seed corpus uses → 90% 1e

CGF uses a seed corpus of inputs that are mutated to explore coverage.

mutation engine uses → 90% 1e

CGF applies mutations to interesting inputs to generate new test inputs.

LINKED ENTITIES

3 links

ProcessorFuzz IMPLEMENTS Extracted graph relationship

DiFuzzRTL IMPLEMENTS Extracted graph relationship

hardware fuzzing USES Extracted graph relationship

CITATIONS

8 sources

8 citations — click to expand

[1] Coverage-based greybox fuzzing uses runtime code coverage information and is described as a dominant methodology for vulnerability discovery. Multi-target Coverage-based Greybox Fuzzing

[2] Superion extends coverage-based greybox fuzzing with grammar-aware trimming and mutation for structured inputs such as XML and JavaScript, reporting improved coverage and bug-finding results. Superion: Grammar-Aware Greybox Fuzzing

[3] Multi-target coverage-based greybox fuzzing uses coverage from cooperating OS and firmware components and runs the system in QEMU to measure coverage across software boundaries. Multi-target Coverage-based Greybox Fuzzing

[4] DIFUZZRTL adapts coverage-guided fuzzing to RTL simulation by identifying control-relevant registers, instrumenting RTL, and hashing monitored register values into a coverage map each clock cycle. ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance

[5] Register-coverage feedback in DIFUZZRTL can be inflated by datapath-related registers that add search space without providing meaningful hardware-state information. ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance

[6] ProcessorFuzz uses CSR-transition coverage to guide processor fuzzing toward interesting processor states and uses an ISA simulator as part of the coverage-feedback mechanism. ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance

[7] Processor fuzzers use differential testing between RTL simulation and a reference ISA simulator because semantic bugs are domain-specific and harder to detect than crash-style memory-safety bugs. ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance

[8] The ProcessorFuzz paper reports that ISA simulation was 79× faster than RTL simulation for the BOOM RISC-V processor as a reference point. ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance