Skip to content
STIMSMITH

Control Flow Edge Coverage

Concept

Control Flow Edge Coverage is a grey-box fuzzing feedback metric that tracks the set of control-flow (CF) edges actually taken during program execution, as opposed to counting basic-block executions. It is the primary coverage signal used by traditional grey-box fuzzers to guide test-case generation, although it can overlook bugs whose triggering conditions are expressed through dataflow rather than control flow alone. Hardware implementations such as TaPaFuzz realize edge coverage by hashing each edge's source and target program counters into a compact coverage map.

First seen 7/12/2026
Last seen 7/12/2026
Evidence 2 chunks
Wiki v1

WIKI

Control Flow Edge Coverage

Definition and Role in Fuzzing

Control Flow Edge Coverage (also referred to as CF edge coverage) is a coverage-feedback metric used in grey-box fuzzing. Instead of recording which basic blocks (BBs) have been executed, CF edge coverage tracks information about the CF edges that were actually taken during a target program's execution. Each edge is identified by its source and target basic blocks (or equivalently, its source and target program counters, PCs).

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

2 connections
TaPaFuzz ← implements 100% 2e
TaPaFuzz implements control flow edge coverage via its FRA hardware unit.
Fuzzer Result Aggregation Hardware ← implements 100% 1e
The FRA hardware implements control flow edge coverage tracking.

CITATIONS

12 sources
12 citations — click to expand
[1] CF edge coverage tracks information on the actually taken CF edges. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[2] The FRA hardware is attached to the CVA5 core via the core's built-in tracing interface, which provides dedicated PC and instruction word outputs. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[3] Based on each CF edge's start and target addresses, the hash algorithm creates pseudo-random address-indexes within the coverage map, whose values count each edge's occurrences. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[4] The hash algorithm implementation needs to enable high throughput, low risk of collisions, and low hardware overhead, while cryptographic security is not a requirement. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[5] The selected lightweight hash runs with only 8 cycles latency and guarantees a throughput of 1 item per cycle, thus not limiting CF throughput. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[6] The 32-bit hash algorithm is fed with the edge's source PC, the destination PC is added to an intermediate value of the algorithm to avoid collisions with nearby CF, and the result's bit-length is trimmed depending on the chosen coverage map size. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[7] The overall jump and branch throughput is limited by the read-and-write round trip time to the result memory, and a direct stall signal into the processor is triggered if required to not miss CFs. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[8] Hash digests identifying entire CF paths guide towards high path coverage, which can be reached by mutating just one loop limit, but miss other relevant CF edges. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[9] CF edges with complex conditions are hard to fuzz because a specific edge is taken only when all partial conditions are met simultaneously. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[10] By splitting the condition over multiple basic blocks, the fuzzer receives more runtime feedback to find inputs that meet all partial conditions; this CF-altering transformation may be inappropriate for real-time IoT targets. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[11] Traditional grey-box fuzzers guide test case generation primarily using control flow edge coverage, which can overlook bugs not easily exposed through control flow analysis alone. FuzzRDUCC: Fuzzing with Reconstructed Def-Use Chain Coverage
[12] On end of execution, the hardware signals an interrupt to the host, which fetches the coverage map, exception status, and cycle count to generate the next fuzzer run's inputs. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing