Overview

Coverage-guided fuzzing (CGF) is a testing technique that uses execution feedback, commonly code coverage, to guide input mutation toward inputs that explore more program behavior. Public research describes CGF as an effective technique that has detected many bugs across software applications and as a technique that focuses on maximizing code coverage during fuzzing. However, the same research cautions that higher coverage does not necessarily imply better fault detection: triggering a bug can require both exercising a particular path and reaching an interesting program state on that path. [CGF definition and coverage caveat]

Feedback signals

The central idea in CGF is to reward inputs that improve the feedback metric used by the fuzzer. The most common framing in the supplied public context is code-coverage maximization, but research also investigates alternative or additional feedback. One mutation-testing study proposes using mutation scores as feedback to guide fuzzing toward bug detection rather than only toward code coverage; in its evaluation on five benchmarks, the modified Zest-based techniques improved both code coverage and bug detection. [Mutation-score feedback]

In the hardware-processor fuzzing literature, traditional processor fuzzers such as DifuzzRTL and TheHuzz use code coverage and control-register coverage as feedback to guide the mutation process, generating seeds through random instruction generation and then mutating instructions in the current input. Hybrid hardware fuzzers such as HyPFuzz and PSOFuzz combine fuzzers with formal tools and optimization algorithms but reuse the seed-generation and mutation engines of traditional processor fuzzers and lack a well-defined feedback signal for producing meaningful instruction sequences that reach deep design regions. [Processor-fuzzer feedback] [Hybrid fuzzers feedback gap]

LLM-based processor fuzzers such as ChatFuzz extend CGF with an LLM-driven input generator that is steered by coverage metrics to produce interdependent, data/control-flow entangled instruction sequences, rather than relying solely on bit/byte-level mutation of existing seeds. ChatFuzz reports reaching 74.96% condition coverage in less than an hour, and finds discrepancies such as attempted writes to the R0 register that violate the RISC-V specification's requirement that R0 remain zero. [ChatFuzz LLM feedback] [ChatFuzz R0 finding]

Reusing historic tests and post-silicon feedback

Recent NDSS 2026 work broadens the feedback space beyond single-run coverage metrics by learning from prior runs and from below-ISA execution. ReFuzz selects and mutates highly effective tests from historic processor designs using contextual bandits to improve vulnerability detection and coverage efficiency on new target processors. Fuzzilicon performs post-silicon fuzzing on x86 CPUs with deep microcode-level instrumentation, extracting feedback directly from the processor's internal microcode execution and combining it with coverage-guided fuzzing to uncover subtle microarchitectural vulnerabilities that are invisible to traditional black-box fuzzing. [ReFuzz contextual-bandit seed reuse] [Fuzzilicon microcode-level feedback]

Golden-reference and two-stage strategies

GoldenFuzz introduces a two-stage fuzzing strategy that decouples test refinement from vulnerability exploration using a fast golden-reference model of the device, enabling efficient and semantically aware hardware fuzzing that achieves high coverage and discovers new high-severity vulnerabilities across RISC-V processors. [GoldenFuzz two-stage strategy]

Coverage plateau and extensions

A recurring challenge for CGF is the coverage plateau: the fuzzer repeatedly generates inputs that fail to reach unexplored areas of the state space, limiting the discovery of bugs and corner cases. This problem is especially pronounced in hardware fuzzing, where stateful behavior, deeply nested conditions, and long execution traces make exploration harder. [Coverage plateau]

Reported behavior from the FuSS evaluation on the RISC-V CVA6 SoC illustrates the plateau: random testing does not improve branch coverage beyond 60%, traditional fuzzing plateaus around 85% after roughly 150 minutes, and fuzzing augmented with property checking plateaus near 88% after roughly 230 minutes due to state-space explosion. The coverage plateau persists across SoC designs: across PicoSoC, UeRVSoC, VeeRwolf, and CVA6, traditional fuzzing plateaus around 80% branch coverage, while fuzzing with property checking still plateaus lower than FuSS due to state-space explosion. State-of-the-art hardware fuzzing solutions reach at most about 70% toggle coverage on the same benchmarks. [CVA6 plateau example] [Multi-SoC plateau] [Toggle coverage ceiling]

To overcome this plateau, hybrid approaches combine CGF with formal techniques. The FuSS framework integrates coverage-guided fuzzing with selective symbolic execution: when a coverage plateau is detected, the framework uses the existing fuzzing trajectory to perform selective symbolic execution and produce a minimal input sequence for hard-to-activate regions, avoiding the large state space that property-checking-based fuzzing must explore from the start state. FuSS evaluates four RISC-V-based SoC designs and reports branch coverage close to 100% in under 10 hours, where traditional fuzzing plateaus around 80%. [FuSS hybrid approach] [FuSS SoC results]

Use in processor/hardware verification

Hardware verification is a major application area for CGF. DifuzzRTL applies coverage-guided fuzzing to differential RTL testing, TheHuzz applies it to instruction fuzzing of processors using golden-reference models, and RFUZZ applies coverage-directed fuzz testing of RTL on FPGAs. [DifuzzRTL processor fuzzing] [TheHuzz processor fuzzing] [RFUZZ RTL fuzzing]

DifuzzRTL in particular introduces a register-coverage metric that is designed to comprehensively capture RTL design states and guide input generation; it automatically instruments this register-coverage into target RTL designs, and pairs it with differential testing against an ISA simulator, random instruction generation, and instruction mutation. [DifuzzRTL register-coverage]

Within a hardware CGF framework such as FuSS, design instrumentation is performed by instantiating the hardware description in a testbench that controls clock and reset, and providing the input instruction sequence as an external byte array with internal segments separating individual instructions. The instrumented hardware description together with the testbench is then converted into a software model, so that software verification tools (both the fuzzer and the symbolic execution engine) can be used on the hardware implementation with minimum modifications. Both engines share the same test-vector corpus. This enables both the fuzzer and a symbolic execution engine to share the same test-vector corpus. [Design instrumentation] [Software model conversion]

CGF-based verification of instruction set simulators themselves has also been investigated, treating the ISS as the target under test. [ISS verification via CGF]

Coverage-plateau detection

Detecting the plateau is non-trivial because coverage may fluctuate around a value rather than monotonically stall. The FuSS framework defines a threshold function P(t) over cumulative code coverage C(t) to decide when to invoke the symbolic execution engine, so that symbolic execution is triggered only when needed. [Plateau detection threshold]

Use beyond conventional software

CGF is also being adapted beyond conventional software targets. The FLARE preprint applies coverage-guided fuzzing to LLM-based multi-agent systems by extracting specifications and behavioral spaces from agent definitions, building test oracles, and fuzzing to expose failures. Its evaluation on 16 open-source applications reports 96.9% inter-agent coverage, 91.1% intra-agent coverage, and 56 previously unknown failures. [FLARE MAS fuzzing]

Limitations

The supplied evidence supports several qualifications. First, the broader CGF literature warns that coverage is not the same as fault-detection capability, because faults can depend on program state as well as path reachability. Second, hardware CGF encounters coverage plateaus that property checking only partially alleviates before also plateauing because of state-space explosion. Third, the coverage plateau varies by metric: even strong CGF runs may leave functional or toggle metrics well below 100% (e.g., toggle coverage capped near 70% in one study, or specific functional-coverage metrics below 100% in the prior ISS evaluation). [CGF definition and coverage caveat] [Toggle coverage ceiling]