Fuzzing Multiple Code Paths Finds More Bugs and Better Coverage Than Single-Mode Testing

Most modern software can be invoked in different ways—via command-line arguments, subcommands, and configuration flags. Yet traditional fuzzing tests typically focus on one execution mode at a time. A new empirical study reveals that this single-minded approach leaves significant portions of code untouched, and that testing multiple modes substantially improves bug detection.

The Multi-Driver Fuzzing Advantage#

Researchers conducted an experiment across 27 open-source projects (encompassing 43 distinct programs and 854 different driver configurations) to understand how different execution modes interact with code coverage. The key insight: when the same fuzzing budget is spread across multiple entry points rather than concentrated on one, software exploration improves dramatically. Programs tested via multiple modes showed 27.9% more covered call-graph nodes and 73.5% higher control-flow-graph edge coverage than the best single-mode approach. Additionally, the multi-mode strategy uncovered 11 unique bugs and abnormal behaviors that single-mode fuzzing consistently missed.

How the Study Works#

The team developed a four-phase methodology grounded in a novel structural abstraction. The approach combines a static call graph—a map of how functions call each other throughout the entire codebase—with dynamic coverage data collected during actual test runs. By projecting the coverage from each execution mode onto this shared backbone, researchers could visualize how different modes explore overlapping versus unique regions of the code. This framework enabled systematic analysis of how individual drivers contribute to overall exploration and where coverage gaps persist.

Uneven Impact and Hidden Patterns#

Not all execution modes are created equal. The analysis found that driver contributions vary widely: some modes unlock significant new code paths, while others provide diminishing returns. The subgraphs reached through different modes exhibit varying degrees of cohesion, fragmentation, and modularity. Importantly, remaining under-explored code doesn't scatter randomly across the codebase—instead, it clusters into predictable patterns rather than fading into a uniform, hard-to-reach tail.

Why This Matters#

The findings reframe multi-driver fuzzing as fundamentally a . Rather than simply running more tests, the real challenge lies in understanding how program structure varies across execution modes and strategically selecting which modes to test to maximize code discovery. This insight could guide more effective fuzzing strategies for complex, multi-mode systems.