Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing BAIHONG CHEN∗ , Utah State University, USA HUA MING, University of Michigan, USA WEIFENG PAN, Zhejiang Gongshang University, China TIAN XIE, Utah State University, USA HAIPENG CAI, University at Buffalo, SUNY, USA WEN LI† , Utah State University, USA Many software systems expose multiple execution modes through command-line options, subcommands, and configuration flags. For such programs, fuzzing depends on both mutated inputs and the invoked mode. Yet evaluations still focus on coverage and bug counts, leaving unclear how execution modes partition, overlap, and miss software structure, and how these differences affect effectiveness. We present an empirical study of software structure under multi-driver fuzzing. We propose a structural abstraction that uses a static

arXiv:2608.12859v1 [cs.SE] 13 Aug 2026

call graph as a shared backbone and projects driver-specific dynamic coverage onto it to derive driver-induced subgraphs. Based on this abstraction, we develop a four-phase methodology for backbone construction, fuzzing and profiling, graph-based analysis, and research-question-driven evaluation. We apply it to 27 OSS-Fuzz-derived C/C++ projects, spanning 43 executables and 854 driver configurations. Under the same total budget, multi-driver fuzzing outperforms the best single-driver baseline, increasing covered call-graph nodes by 27.9% and CFG-edge coverage by 73.5%, and revealing 11 unique bugs and abnormal behaviors largely missed by single-driver fuzzing. However, driver contributions are uneven, subgraphs differ substantially in cohesion, fragmentation, modularity, overlap, and residual under-exploration follows recurring regimes rather than a homogeneous tail. These results show that multi-driver fuzzing is fundamentally a structural exploration problem. CCS Concepts: • Software and its engineering → Software testing and debugging; • Security and privacy → Software and application security. Additional Key Words and Phrases: Fuzzing, Program Analysis, Software Security ACM Reference Format: Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li. 2026. Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing. 1, 1 (August 2026), 40 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn ∗ First author † Corresponding author

Authors’ Contact Information: Baihong Chen, Utah State University, USA, b.chen@usu.edu; Hua Ming, University of Michigan, USA, huaming@umich.edu; Weifeng Pan, Zhejiang Gongshang University, China, wfpan@zjgsu.edu.cn; Tian Xie, Utah State University, USA, tian.xie@usu.edu; Haipeng Cai, University at Buffalo, SUNY, USA, haipengc@buffalo.edu; Wen Li, Utah State University, USA, awen.li@usu.edu.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. © 2026 ACM. Manuscript submitted to ACM Manuscript submitted to ACM

1

2 1

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li Introduction

Modern software systems often expose rich functionality through command-line options, subcommands, configuration flags, and input formats. In such programs, different execution modes can activate substantially different parsing logic, control-flow paths, and downstream functionality. For fuzzing, this means that software is rarely explored through a single uniform mode. Instead, the reachable behavior of a program is shaped jointly by mutated inputs and by the execution mode under which the program is invoked. This challenge is especially relevant for command-line and configuration-rich software, where invocation choices can partition program behavior into partially overlapping functional regions [24, 36, 43, 47]. Existing fuzzing research has largely focused on improving testing effectiveness through better guidance, mutation strategies, static analysis, and hybrid analysis, including work on command-line and configuration-rich software as well as broader program-environment fuzzing [22, 26, 30, 33, 52, 57, 58]. These efforts have significantly advanced fuzzing, while empirical studies have also improved understanding of how fuzzers should be evaluated, typically through aggregate outcomes such as code coverage, bug-finding effectiveness, crashes, and benchmark quality [14, 17, 20, 34]. However, prior work has primarily treated options, execution modes, and environmental diversity as means to improve fuzzing effectiveness, rather than as objects of structural analysis. As a result, they reveal relatively little about how different execution modes of the same program relate to one another structurally. In particular, it remains poorly understood whether multiple execution modes explore complementary functional regions, whether they are largely redundant, how their induced execution footprints are organized, and why substantial parts of a program may remain under-explored even under multi-driver fuzzing. This gap leaves driver complementarity, redundancy, and residual blind spots insufficiently characterized, with potential implications for fuzzing efficiency under multi-driver settings. This paper takes a different perspective. Rather than proposing a new fuzzing algorithm, it presents an empirical study of software structure as observed through multi-driver fuzzing. Our key idea is to analyze different execution modes in a shared graph space: for each target program, we use a static function-level call graph as a common structural backbone and map driver-specific dynamic coverage onto that backbone to derive driver-induced subgraphs. This representation makes it possible to compare how execution modes partition, share, and miss program structure while keeping the analysis grounded in behavior that fuzzing actually exercises. Using this perspective, we design a four-phase empirical methodology that combines structural backbone construction, multi-driver fuzzing and profiling, graph-based structural analysis, and research-question-driven evaluation. We implement this methodology with lightweight execution and analysis support, and apply it to a diverse benchmark suite derived from OSS-Fuzz, covering 27 projects, 43 executables, and 854 driver configurations across multiple software domains, including media processing, document and parser utilities, toolchain and binary analysis tools, language runtimes, archive and compression software, network/protocol utilities, and database/storage systems. Our study shows that the effectiveness of multi-driver fuzzing is fundamentally shaped by software structure. The key findings and implications are summarized as follows: • Multi-driver fuzzing generally outperforms the best single-driver baseline under the same total budget, improving coverage by an average of 27.9% in covered call-graph nodes and 73.5% in covered CFG edges. Beyond coverage, MFuzz also demonstrates clear practical value for bug discovery: it exposed 11 unique bugs and abnormal behaviors across the benchmark suite, most of which were not recovered by the strongest single-driver configuration. These results indicate that preserving driver diversity is important not only for expanding structural reach, but also for uncovering semantically specialized failure behaviors that remain inaccessible to single-driver fuzzing. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

3

• Equal-budget round-robin execution yields highly uneven driver contributions, and driver-induced subgraphs differ substantially in size, cohesion, fragmentation, modularity, and pairwise overlap. This shows that multidriver fuzzing is not simply a matter of adding more drivers: its benefit depends on the marginal structural contribution, complementarity, and redundancy of drivers. • The remaining cold structure does not form a single homogeneous tail. Instead, executables exhibit recurring residual-gap regimes, ranging from backbone-dominated residual gaps, to substantial residual tails, to localized residual pockets. This suggests that persistent under-exploration takes qualitatively different forms across executables. • These findings suggest several practical directions for driver-aware fuzzing. Effective approaches should measure the marginal value of each driver, account for overlap and redundancy among drivers, prioritize drivers that continue to extend exploration into weakly covered regions, and adapt effort allocation to different residual regimes, rather than relying solely on uniform round-robin execution or aggregate coverage. Taken together, these results show that multi-driver fuzzing is not merely a matter of using more drivers, but of understanding how different execution modes partition, overlap, and leave under-explored regions in the shared program backbone. This paper makes the following contributions: • We present an execution-driven structural abstraction for studying configuration-rich software under fuzzing, based on a shared function-level call graph and driver-induced subgraphs derived from dynamic execution. • We develop lightweight tool support, MFuzz and GDissert, that operationalizes controlled multi-driver execution, strict per-driver runtime attribution, and offline graph-based structural analysis for empirical study. • We develop a scalable empirical methodology and structural metric set for analyzing exploration scope, cohesion, fragmentation, modularity, overlap, and region-level under-exploration across execution modes. • We conduct a large-scale empirical study on OSS-Fuzz-derived benchmarks and provide a systematic graphlevel characterization of how multi-driver fuzzing explores software structure, including recurring residual-gap regimes and their implications for driver-aware fuzzing. Open Science To support transparency, reproducibility, and follow-up research, we make the artifacts used in this study publicly available at GraphDissect. These artifacts include: (i) the benchmark list and executable metadata, (ii) the manually specified driver configurations, and (iii) the scripts and tool support used for multi-driver fuzzing and structural analysis. We also document the experimental environment, execution workflow, and artifact organization to facilitate reuse by other researchers. By releasing both the execution-side and analysis-side artifacts, we aim to enable independent verification of our results and to support future work on driver-aware fuzzing, structural coverage analysis, and benchmark construction. 2

Background & Related Work

This section first introduces the background concepts underlying our study, including call graphs, fuzzing, and multimode execution, and then positions the study relative to prior work on fuzzing and program analysis. 2.1

Program Structure and Call Graphs

A call graph models the interprocedural structure of a program by representing functions as nodes and call relationships as directed edges [16]. Call graphs are widely used to reason about program organization, modularity, and interprocedural Manuscript submitted to ACM

4

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

behavior. Depending on how they are constructed, call graphs may be static or dynamic, and context-sensitive or contextinsensitive. Static call graphs are typically derived through whole-program analysis and conservatively approximate the set of possible call relationships. To preserve soundness, such analyses often over-approximate indirect calls caused by function pointers, callbacks, or virtual dispatch, especially in large C/C++ systems [16, 25, 35]. Dynamic call graphs, in contrast, record only the call edges exercised during execution, yielding precise but incomplete views of program behavior [15]. In this work, call graphs provide the structural basis for reasoning about how different executions relate to the same program. A function-level call graph offers a common granularity for comparing exercised program regions across heterogeneous software systems while remaining scalable to large real-world applications. 2.2

Fuzzing and Dynamic Program Analysis

Fuzzing is a widely used dynamic testing technique that generates large numbers of inputs to explore program behaviors and discover bugs [24]. Modern greybox fuzzers use lightweight instrumentation to guide input mutation through coverage feedback, such as basic-block or edge coverage [36, 47]. This feedback-driven design has made fuzzing one of the most effective approaches for testing complex input-processing software. At the same time, fuzzing observes program behavior only through concrete executions. The coverage collected during fuzzing therefore reflects the portions of the program reached under a particular set of inputs and configurations [32], rather than the full set of statically possible behaviors. As a result, fuzzing naturally yields partial but execution-grounded observations of program structure. This execution-driven property is especially useful for studying how software is explored in practice. Rather than attempting to reconstruct complete calling contexts or precise execution traces, one can use coverage collected during fuzzing as a scalable signal for which functional regions are actually exercised. 2.3

CLI Programs and Multi-Mode Execution

Many real-world software systems, especially command-line utilities, expose multiple execution modes through subcommands, options, flags, configuration settings, or input formats [43]. Such programs are also common among practical fuzzing targets, including many projects in OSS-Fuzz and in our benchmark suite [14]. Examples include command-line tools such as xpdf, jq, xmllint, and ffmpeg, which provide distinct functionality through different options, subcommands, or input modes [7, 12, 19, 54]. These invocation modes often activate different parsing logic, control-flow paths, and downstream functionality within the same executable. As a result, the code exercised under one mode may differ substantially from that exercised under another. This property is especially important in fuzzing, where program behavior depends not only on mutated input bytes but also on how the target is invoked. Compared with single-mode programs, CLI targets with rich mode-dependent behavior therefore present a broader and more heterogeneous exploration space. Understanding how these execution modes relate to exercised program structure is important for analyzing overlap, diversity, and uneven exploration across complex software systems. 2.4

Related Work on Fuzzing and Program Analysis

Prior work has explored the use of static and dynamic program analysis to improve fuzzing effectiveness. Existing techniques have used control-flow and data-flow information to identify targets, prioritize exploration, guide mutations, or increase reachability to difficult program locations [26]. Other approaches combine fuzzing with symbolic execution or related hybrid analyses to mitigate path explosion and improve behavioral coverage [57]. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

5

Related work has also shown that the structure of a target program affects fuzzing behavior. Coverage feedback, control-flow organization, and input-dependent execution diversity all influence which parts of a program are explored and which remain difficult to reach [36, 47, 58]. A closely related line of work studies fuzzing for command-line and configuration-rich software, where program behavior depends not only on mutated inputs but also on how the target is invoked. Recent approaches have explored option-aware and CLI-oriented fuzzing, including automatic extraction of program-option constraints from documentation, coverage-guided combinatorial exploration of commandline interfaces, and interleaved fuzzing of program options and file inputs [22, 30, 52]. More broadly, prior work in combinatorial interaction testing has shown the importance of systematically exercising parameter combinations and configuration constraints [10, 56]. These studies demonstrate that invocation modes and option combinations can substantially affect coverage and bug discovery. Related work has also considered fuzzing the broader program environment. Program environment fuzzing records and replays observed environmental interactions at the kernel/usermode boundary, with selective mutations applied to explore different concrete program environments without explicit environment modeling [33]. This line of work shows that environmental interactions can affect program behavior and bug discovery. However, it primarily aims to extend fuzzing to richer environmental inputs for bug finding, rather than to characterize structural relationships among different execution modes of the same program. Overall, these studies primarily treat options, execution modes, or environmental diversity as means to improve fuzzing effectiveness, rather than as objects of structural analysis. Beyond fuzzing techniques, several empirical studies have examined fuzzing behavior, benchmarking practice, and evaluation methodology. Prior work has analyzed the reliability of fuzzing evaluations, the reproducibility of coverage and bug-finding results, and the importance of benchmark design in comparing fuzzers [14, 17, 20, 34]. These studies have improved understanding of how fuzzers should be evaluated, but they mainly focus on aggregate outcomes such as coverage, crashes, and benchmark quality, rather than on how different execution modes partition and share the software structure of the same target. Most prior studies therefore focus either on improving fuzzing guidance, extending fuzzing to richer inputs and environments, or on evaluating fuzzers through aggregate effectiveness measures, rather than explicitly analyzing the graph-level structural relationships among execution modes of the same program. Compared with these approaches, our work does not propose a new fuzzing algorithm or guidance strategy. Instead, it studies software structure as observed through fuzzing, using a static call graph as a common structural backbone and dynamic execution coverage as an execution-grounded signal of explored functionality. This design emphasizes structural characterization rather than fuzzing optimization.

2.5

Positioning of This Study

This study differs from prior work in both goal and methodology. Rather than improving fuzzing guidance directly, we aim to understand how software structure is explored across different execution modes of the same program. Our focus is on how exercised program regions diverge, overlap, and remain under-explored under multi-mode fuzzing. Methodologically, the study combines a unified static structural representation with execution-derived observations from fuzzing. This combination makes it possible to compare exercised regions across drivers, executables, and benchmarks in a common graph space while keeping the analysis grounded in behavior that actually occurs during testing. The resulting perspective complements existing work on fuzzing and program analysis by revealing structural properties that are difficult to observe from aggregate coverage alone. Manuscript submitted to ACM

6 3

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li Study Goals and Overview

The goal of this work is to empirically characterize how software structure is exercised under different execution modes. Modern software systems often expose rich functionality through command-line options, configuration flags, and input formats. Each configuration may activate a different subset of program behavior, yet the structural relationships among these execution modes remain poorly understood. This paper presents an empirical study of software structure as observed through fuzzing. Rather than proposing a new fuzzing or analysis technique, we focus on measuring and analyzing the structural properties of real-world programs under multi-driver execution. We model software structure at the function level and study how different drivers activate overlapping or distinct regions of the same program. Our objective is to provide a systematic understanding of structural diversity, sharing, and under-exploration in multi-driver software systems. To enable consistent analysis across heterogeneous programs, we adopt a unified graph-based representation. For each target program, we construct a static, context-insensitive call graph as a shared structural backbone. Using fuzzing-driven dynamic profiling, we then identify, for each driver, the subset of functions exercised during execution. This yields a driver-induced subgraph for each execution mode, allowing direct comparison of drivers using a common set of structural metrics. Using this framework, we investigate the following research questions: • RQ1: Does multi-driver fuzzing achieve greater overall coverage than the best single driver under the same total fuzzing budget? We compare the union multi-driver results with those of the best individual driver while keeping the total fuzzing budget constant. Specifically, we evaluate both function-level structural coverage on the call-graph backbone and final CFG edge coverage. • RQ2: Do drivers exhibit heterogeneous fuzzing effectiveness under equal time budgets? We allocate the same fuzzing time to each driver and compare their individual outcomes, including call-graph node coverage, CFG edge coverage, and discovered bugs. • RQ3: How are driver-induced subgraphs structurally organized? We analyze the size, connectivity, fragmentation, and modularity of driver-induced subgraphs to examine how different execution modes activate and organize program structure. • RQ4: To what extent do drivers overlap in the functionality they cover? We measure pairwise overlap between drivers using intersection-over-union (IoU) over covered functions and call edges. • RQ5: Which structural regions remain under-explored after round-robin multi-driver fuzzing, and why? We identify residual low-coverage regions in the shared structural backbone after multi-driver fuzzing and analyze the main causes of these gaps through representative case studies. These questions are designed to address the study goal from complementary empirical perspectives. Measuring overall effectiveness is necessary to determine whether multi-driver execution changes exploration outcomes in a meaningful way. However, aggregate outcomes alone are insufficient, because they do not reveal whether the observed behavior is shared across drivers or dominated by only a few execution modes. For this reason, the study further examines variation across drivers and then analyzes the structure and overlap of their induced subgraphs, so that differences in exploration can be interpreted in terms of shared and distinct program regions. The analysis finally extends to residual under-explored structure, which is necessary for understanding what parts of the shared backbone remain weakly exercised after combining drivers. In this way, the questions collectively connect outcome-level measurement with structural characterization and residual-gap analysis to support the overall empirical goal of understanding how software structure is exercised under multi-driver fuzzing. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing 4

7

Methodology

This section presents the methodology of our empirical study. We first introduce the overall study design and the structural abstraction used to analyze software structure under fuzzing. We then describe the four study phases: benchmark selection, structural backbone construction, fuzzing and execution profiling, and structural analysis and evaluation. Finally, we summarize the experimental setup and tool support used to operationalize the study. 4.1

Study Design Overview

This study empirically examines how software structure is exercised and explored under different execution modes. We focus on understanding how distinct drivers activate overlapping or disjoint functional regions of a program, how these regions evolve during fuzzing, and where existing fuzzing campaigns leave structural gaps. To this end, we model software structure at the function level and analyze driver-induced subgraphs derived from dynamic execution. • Candidate Pool and Domain Organization • Benchmark Selection

• Call-Graph Construction • Driver Specification

• Fuzzing Execution • Driver-Induced Subgraph Projection

• Structural Metric Computation • RQ-Driven Evaluation

Phase I Benchmark Selection

Phase II Structural Backbone Construction

Phase III Fuzzing and Execution Profiling

Phase IV Structural Analysis and Evaluation

Fig. 1. Overview of the empirical study methodology.

Figure 1 summarizes the overall workflow of the study. The methodology proceeds in four phases. Phase I defines the benchmark space by organizing the candidate pool and selecting the final benchmarks. Phase II constructs a wholeprogram function-level call graph for each executable and specifies driver configurations representing distinct execution modes. Phase III runs fuzzing under each driver, collects driver-attributed execution profiles, and projects covered functions onto the shared call-graph backbone to obtain driver-induced subgraphs. Phase IV computes structural metrics over these subgraphs and organizes the resulting measurements to answer RQ1–RQ5. This phased design enables systematic measurement of software structure from an execution-driven perspective. By separating structural preparation, dynamic data collection, structural analysis, and evaluation, the study ensures that observations are both precise and comparable across programs. Using a unified structural backbone allows driver-specific behaviors to be analyzed within a consistent representation, while dynamic profiling grounds the analysis in behaviors actually observed during fuzzing. Together, these phases provide a scalable and principled framework for empirically studying software structure and fuzzing effectiveness across diverse real-world systems. 4.2

Execution-Driven Structural Abstraction

Rather than analyzing program structure solely as a static property, we focus on the structural regions that are actually exercised during fuzzing. This design choice is central to our methodology. While static call graphs provide a programwide view of potential interprocedural relationships, they inevitably over-approximate runtime behavior, especially in large C/C++ systems with indirect calls, callbacks, and configuration-dependent execution paths [16, 25, 35]. As a result, purely static structures often contain regions that are unreachable, infeasible, or irrelevant to the executions observed in practice. Fuzzing, by contrast, explores programs through concrete executions generated under specific inputs and execution modes. From this perspective, the structure most relevant to fuzzing is not the full set of statically possible relationships, Manuscript submitted to ACM

8

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

but the subset that is actually activated during execution [32]. Grounding the study in execution-derived structure therefore allows us to analyze software as fuzzing encounters it in practice: which regions are exercised, which execution modes reach distinct functionality, where structural overlap exists across drivers, and which regions remain persistently unexplored. Based on this view, we adopt a hybrid structural abstraction. Each target program is represented by a function-level static call graph, in which nodes denote functions and edges denote potential interprocedural call relationships. This graph serves as a unified structural backbone shared across all drivers and fuzzing runs. Dynamic execution profiles collected during fuzzing are then projected onto this backbone, so that the study can compare structurally different executions within a common reference space. This abstraction captures the interprocedural structure relevant to our analysis while remaining lightweight enough for systematic comparison across benchmarks. Figure 2 illustrates this idea using xmllint [12]. Although the program has a single static structural backbone rooted at xmllintMain, different execution modes activate different functional regions. For example, the default mode primarily exercises XML parsing logic, whereas –html activates HTML parsing routines and –schema further triggers schema-processing functionality. Thus, even though all executions are embedded in the same program structure, their effective exploration footprints differ substantially. main

xmllintMain (--schema) xmlSchemaParse

------

Schema validation subsystem

parseAndPrintFile parseFile (--html) htmlReadFile

------

(XML mode) xmlCtxtReadFile

HTML parsing subsystem ------

XML parsing subsystem

Fig. 2. Example of driver-induced structural divergence in xmllint. All execution modes share a common structural backbone rooted at xmllintMain. Depending on the driver configuration, execution diverges into distinct functional regions, such as schema parsing (–schema), HTML parsing (–html), or XML parsing (default mode). Each driver thus induces a subgraph of the unified call graph, resulting in overlapping but non-identical structural coverage.

To represent these execution modes explicitly, we treat drivers as the primary unit of analysis. A driver corresponds to a concrete execution configuration of a target program, defined by its options, expected input format, and seed corpus. Formally, a driver configuration 𝑑 is defined as 𝑑 = ⟨id, opts, fmt, 𝑆𝑑 ⟩, where id is a unique driver identifier, opts is the set of execution options and flags, fmt is the expected input format, and 𝑆𝑑 is the seed corpus used to initialize fuzzing for that driver. Each driver is intended to represent a semantically distinct execution mode and typically activates a characteristic subset of program functionality. Under this abstraction, dynamic execution profiles collected during fuzzing are attributed to driver identifiers and later mapped onto the shared call-graph backbone. This yields driver-induced subgraphs, which capture the effective structural regions explored by each driver. These subgraphs form the basis of the subsequent analysis: they allow us to quantify structural diversity across drivers, measure overlap and imbalance in explored regions, and relate structural exploration patterns to fuzzing outcomes such as coverage and crashes. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

9

Overall, this hybrid design combines the strengths of static and dynamic views. The static call graph provides a consistent program-wide reference, while dynamic execution profiles ensure that the analysis remains grounded in behavior that fuzzing actually exercises. This combination enables a systematic empirical study of how software structure is explored, shared, and missed across different drivers and benchmarks. 4.3

Phase I: Benchmark Selection

This phase defines the benchmark space and study scope. Its goal is to select a benchmark set that is broad enough to capture structural variation across software domains while remaining focused on programs whose execution modes can be meaningfully represented as drivers. 4.3.1 Candidate pool and domain organization. We base our empirical study on real-world open-source software drawn from OSS-Fuzz [14], a large-scale continuous fuzzing platform maintained by Google. OSS-Fuzz provides standardized build environments, fuzzing infrastructure, and security-relevant target programs, making it a suitable and widely used source for empirical fuzzing studies. From the full OSS-Fuzz project pool, which contains 1325 projects at the time of our study, we restrict the benchmark space to programs implemented primarily in C or C++. This choice is motivated by two considerations. First, C/C++ projects are a natural focus within OSS-Fuzz, where C/C++ is directly supported and analysis support is especially mature [14]. Second, our study requires reliable whole-program analysis and function-level instrumentation, both of which are well supported in the LLVM/Clang ecosystem for C/C++ [21, 46]. The resulting C/C++ project set contains 501 projects and forms the candidate pool for subsequent domain analysis and benchmark selection. Table 1. Domain distribution of C/C++ OSS-Fuzz [14] projects used for candidate benchmark selection. Projects are manually grouped by dominant application domain. Code size is measured in KLoC (thousand lines of code) and reported as the observed min–max range per domain (excluding zero-LOC entries).

No.

#Projects

Code Size Range (KLoC)

1

Network and protocols

170

2.44–7,942.90

2

Media processing

94

2.62–2,241.49

3

Metadata and system utilities

58

4.69–1,934.10

4

Parsing and document processing

69

2.96–5,114.92

5

Toolchain / binary utilities

22

7.16–9,542.76

6

Archive and compression

22

4.63–274.44

7

Language runtimes / interpreters

23

2.60–4,113.27

8

Database and storage

16

7.63–6,064.44

9

OS / system software

20

3.82–1,709.08

10

Machine learning

7

52.33–3,171.45

501

2.44–9,542.76

Total

Domain

Domain Description Network-facing software processing protocols and remote inputs. Audio, video, and image codecs and processing pipelines. Libraries and utilities for configuration, logging, and system metadata. Grammar- and format-driven parsers for structured data and documents. Compilers, linkers, and tools operating on binaries or intermediate representations. Compression libraries and archive manipulation utilities. Language runtimes and interpreters executing user programs. Storage engines and libraries for persistent data management. Operating-system components and low-level system services. Machine-learning frameworks and numerical computation libraries. – Manuscript submitted to ACM

10

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li To ensure diversity in application characteristics, we manually organize the candidate projects by dominant appli-

cation domain. This grouping provides a coarse-grained but useful view of the candidate pool: in empirical software engineering, the diversity and type of studied systems affect how broadly findings can be interpreted, and software taxonomies help relate evidence to its context [1, 9, 37]. The domain categories used here therefore emphasize dominant functionality and input-processing role, which are the aspects most relevant to driver-based structural exploration under fuzzing. In addition, prior fuzzing benchmark efforts have emphasized the importance of using diverse, representative, and real-world targets to avoid overfitting and to improve the realism of evaluation [17, 34]. Each project is assigned to exactly one domain according to its primary artifact, dominant entry-point behavior, and core functionality. To improve labeling consistency, the assignment is based on project documentation, repository descriptions, and the purpose of the fuzzed executable, with ambiguous cases revisited through joint inspection of these sources. When a project spans multiple functionalities, it is assigned to the domain that best reflects its dominant use case and execution behavior. Table 1 summarizes the resulting domain distribution. 4.3.2 Benchmark Selection. From the domain-organized candidate pool, we select a subset of benchmarks for detailed study. The selection is guided by three criteria. First, we seek scale diversity by choosing projects that span different code sizes within each domain. Second, we require execution-mode richness, so that each selected target exposes multiple meaningful execution modes through command-line options or subcommands, and therefore supports driver-based analysis. Third, we prioritize practical relevance, favoring actively maintained and widely used projects whose structure and security exposure reflect realistic fuzzing targets. This strategy yields a benchmark set that balances breadth and depth. It preserves diversity across domains, architectural styles, and program scales while keeping the set manageable for detailed structural analysis. The final benchmark set is shown in Table 2. The selected benchmarks reflect a broad class of user-space input-processing software commonly fuzzed in practice. Across domains, they exhibit the characteristics most relevant to this study: multiple execution modes, non-trivial internal structure, option-driven behavior, and sufficiently rich functional decomposition to induce distinct structural footprints. As a result, the structural phenomena examined here, including driver-induced divergence, overlap, and coverage imbalance, are observed across diverse software systems rather than being tied to a single application class. We intentionally exclude categories such as operating-system kernels, low-level firmware, and machine-learning frameworks. These systems are less aligned with the central abstraction of this study, which focuses on executionmode-dependent structural exploration through explicit driver configurations. By contrast, user-space applications and utilities more naturally expose interchangeable execution modes through options, formats, and subcommands, making them a better fit for analyzing how fuzzing interacts with software structure across drivers. 4.4

Phase II: Structural Backbone Construction

In Phase II, we prepare a unified structural representation for each target executable and define the driver configurations used throughout the study. 4.4.1 Call-Graph Construction. This component constructs a whole-program, function-level call graph that serves as the unified structural backbone for analysis. We obtain call graphs through static analysis of the target program, resolving both direct and indirect call relationships using the flow-sensitive pointer analysis component of SVF [45]. This analysis conservatively approximates possible call targets, yielding a call graph that captures potential interprocedural relationships among functions without relying on execution-specific information. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

11

Table 2. Benchmarks used in the empirical evaluation. All programs are selected from OSS-Fuzz and expose multiple execution modes through command-line options or input formats.

Domain

Network and protocols

Media processing

Metadata and system utilities

Benchmark

LOC (K)

9 10 7 3 2 19 28 7 7 21 32 30 12 6 4 7 4 12 12 25 66 40 18 22 29 8 48 29 23 6 27 36 15 13 22 17 12 12 37 17 22 30 48

258,746

854

sqlite3 [44]

289.5 9,262.0

43

367.1

unbound [39]

137.6

http-parser [40]

6.2

ffmpeg [7]

1,348.5

libtiff [29]

91.9

wavpack [53]

85.6

git [11]

307.0

sleuthkit [49]

284.6

file [8]

188.0

xpdf [54]

493.2

libxml2 [12] jq [19]

139.1 32.4

binutils [13]

3,134.9

cppcheck [4] libdwarf [28] cpython3 [41]

278.4 129.4 763.7

quickjs [42]

76.3

lua [31]

21.3

libarchive [27]

168.9

upx [51] xz [55]

144.3 34.4

hdf5 [48]

739.4

netcdf [50]

296.6

Database and storage

Total

#Drivers

50,881 4,528 2,786 26 20 29,709 29,303 679 697 818 310 206 184 12,714 5,027 393 5,367 331 2,686 2,712 3,001 2,796 800 3,993 1,551 2,825 37,281 1,592 13,953 1,944 1,947 1,148 2,223 606 5,824 749 5,643 5,624 5,632 2,476 2,721 2,404 2,636

27

snort3 [3]

Toolchain / binary utilities

Archive and compression

#Functions

snort snort2lua checkconf parsertrace url_parser ffmpeg ffprobe tiff2bw tiffinfo tiff2pdf wavpack wvunpack wvgain git istat img_stat tsk_recover file pdfdetach pdfinfo pdftops xmllint jq objdump readelf addr2line cppcheck dwarfdump python qjs qjsc lua bsdtar bsdunzip upx xz h5dump h5ls h5repack ncdump ncgen nccopy sqlite3

Parsing and document processing

Language runtimes / interpreters

Executable

A static call graph provides a stable and consistent reference structure that is shared across all drivers and fuzzing runs. Although such graphs may over-approximate feasible execution paths, they enable systematic comparison of Manuscript submitted to ACM

12

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

driver-induced subgraphs across execution modes and benchmarks. Moreover, this design avoids the substantial instrumentation, runtime overhead, and scalability limitations associated with context-sensitive or trace-level representations, making it suitable for large-scale empirical analysis. Importantly, our study does not require exact call precision, as all structural measurements are grounded in dynamically observed coverage projected onto this static backbone. 4.4.2 Driver Specification. Based on the driver abstraction defined in Section 4.2, we manually specify the concrete driver configurations used in the study. Each driver is instantiated as a fixed execution configuration with a unique identifier, together with its command-line options, expected input format, and seed corpus. For each target program, we maintain a one-to-one mapping between driver identifiers and their corresponding execution parameters. During fuzzing, each execution is launched under one such configuration, and all produced artifacts, including coverage and crashes, are attributed to the corresponding driver identifier. This operationalization ensures that later profiling and structural analysis remain driver-specific throughout the pipeline. Manual specification ensures that each driver corresponds to a semantically meaningful execution mode rather than a superficial variation of inputs. It also avoids ambiguities that may arise from automated option inference or dynamically changing configurations, thereby improving reproducibility, interpretability, and reliable cross-driver comparison. In addition, each driver configuration is manually validated before inclusion to ensure that it is executable under the target program, accepts the intended input form, and can serve as a stable basis for fuzzing. We intentionally focus driver construction on primary command-line options and major CLI modes rather than exhaustively enumerating all possible option combinations or other execution-shaping factors. This restriction keeps the driver space interpretable and comparable across heterogeneous programs, while allowing the study to focus on execution modes that are more likely to correspond to distinct functional behavior. The resulting drivers therefore represent a controlled and representative abstraction for empirical analysis. [{ "id": 1, "program": "xmllint", "opts": [], "fmt": "xml", "seeds": “/seeds“ }, Driver 1

{ "id": 2, "program": "xmllint", "opts": ["--html"], "fmt": "html", "seeds": “/seeds“ }, Driver 2

{ "id": 3, "program": "xmllint", "opts": ["--schema", "schema.xsd"], "fmt": "html", "seeds": “/seeds“ }] Driver 3

Fig. 3. Example JSON specifications for three xmllint driver configurations corresponding to XML parsing, HTML parsing, and XML schema validation. Each driver is assigned a unique identifier and a fixed seed corpus.

Example. We illustrate driver specification using xmllint in Figure 3, where different command-line modes activate distinct parsing and validation components (Figure 2). In our study, each driver is recorded as a JSON object ⟨id, opts, fmt, 𝑆𝑑 ⟩, where id uniquely identifies the execution mode, opts encodes the command-line configuration, fmt denotes the intended input format, and seeds points to a fixed seed corpus used to initialize fuzzing. The first driver targets the default XML parsing mode. The second driver enables HTML parsing via –html, inducing a distinct structural region. The third driver enables schema validation by providing –schema together with a schema file, which triggers schema compilation and validation routines in addition to XML parsing. In all cases, the fuzzer starts from the corresponding seed corpus and attributes all observed coverage and crashes to the driver identifier. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing 4.5

13

Phase III: Fuzzing and Execution Profiling

In Phase III, we run fuzzing under the configured drivers and collect the execution profiles used in later structural analysis. The goal of this phase is to expose each target program to multiple execution modes under a controlled and comparable setting while recording the driver-specific runtime artifacts needed for subsequent analysis. 4.5.1 Fuzzing Execution. For each target program, we conduct fuzzing across the configured set of drivers under a fixed shared time budget. Each driver is treated as a distinct execution mode, and the total fuzzing time is divided equally across all drivers so that each one is evaluated under comparable resource constraints. Driver execution follows a round-robin policy, where fuzzing iterates through the driver set and activates one configuration at a time. When a driver is selected, fuzzing proceeds under its associated execution parameters, including command-line options and seed corpus. During its assigned time slice, the fuzzer repeatedly generates inputs and executes the target program under that configuration. This process is repeated across all drivers until the total fuzzing budget is exhausted. By using the same fuzzing engine, mutation workflow, and execution environment throughout the study, we ensure that differences observed across drivers are attributable to the execution modes themselves rather than to variations in experimental setup. This execution policy supports fair cross-driver comparison in two ways. First, equal time allocation prevents the observed results from being dominated by a small subset of drivers that receive more resources. Second, round-robin scheduling ensures that all drivers are exercised under the same overall fuzzing conditions, which improves the comparability of their coverage, crash outcomes, and structural footprints. 4.5.2 Driver-Induced Subgraph Projection. While fuzzing is in progress, we continuously collect driver-specific execution profiles for later analysis. These profiles include the runtime artifacts needed to relate fuzzing behavior to software structure, including covered functions, covered control-flow edges, and discovered crashes. All such artifacts are attributed to the active driver configuration under which the execution occurs. To preserve this attribution, profiling is maintained separately for each driver throughout the fuzzing process. Coverage and crash artifacts observed during a driver’s execution slice are recorded under that driver identifier. The covered functions are then projected to the shared whole-program call graph introduced in Phase II (Section 4.4), yielding a driver-specific execution footprint that can be analyzed in later phases. In this way, Phase II converts fuzzing executions into driver-attributed structural observations. This profiling design is important for the goals of the study. Because the analysis focuses on how different execution modes explore overlapping or distinct program regions, runtime artifacts must remain attributable to individual drivers rather than aggregated across the program as a whole. Maintaining per-driver profiles therefore enables later phases to compare structural diversity, overlap, imbalance, and uncovered regions across execution modes in a principled way. 4.6

Phase IV: Structural Analysis and Evaluation

Phase IV quantifies how fuzzing explores software structure under different drivers. Given the driver-induced subgraphs obtained in Phase III (Section 4.5), this phase measures their size, internal organization, overlap, and region-level exploration patterns. The goal is not only to describe the structural footprints reached by individual drivers, but also to understand how these footprints differ across execution modes and how they relate to fuzzing outcomes. All measurements are computed on driver-induced subgraphs derived from observed executions, using the whole-program static call graph as a shared structural reference. This design enables comparisons across drivers and executables in a common graph space, while keeping the analysis grounded in structure that fuzzing actually exercises. Manuscript submitted to ACM

14

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

4.6.1 Structural Metric Computation. Let the whole-program static call graph be 𝐺 = (𝑉 , 𝐸). For a given driver 𝑑, let its driver-induced subgraph be 𝐺𝑑 = (𝑉𝑑 , 𝐸𝑑 ), where 𝑉𝑑 ⊆ 𝑉 and 𝐸𝑑 ⊆ 𝐸 denote the functions and call edges activated by fuzzing through driver 𝑑. To analyze structural exploration systematically, we organize the metrics into five purposes: (1) measuring exploration scope, (2) characterizing cohesion and fragmentation, (3) capturing internal community organization, (4) quantifying redundancy and complementarity across drivers, and (5) identifying under-explored structural regions. 1 Metrics for exploration scope. To measure how much program structure a driver reaches, we use subgraph size.

Subgraph size. For each driver-induced subgraph 𝐺𝑑 , we measure its size using the number of activated functions and call edges, i.e., |𝑉𝑑 | and |𝐸𝑑 |. This metric captures the structural footprint of a driver. A larger value indicates that the driver reaches a broader interprocedural region of the program, whereas a smaller value indicates that execution remains confined to a narrower structural footprint. We include this metric because exploration size is the most basic indicator of how much structure has been exercised, and it provides a natural baseline for interpreting the more detailed structural measurements below. 2 Metrics for structural cohesion and fragmentation. To distinguish whether a driver explores one dominant structural

region or several scattered ones, we measure both the dominance of the largest connected region and the total number of disconnected regions. Largest Connected Component (LCC) ratio. To measure the cohesion of a driver-induced subgraph, we compute the fraction of activated functions contained in its largest weakly connected component [38]: LCC(𝐺𝑑 ) =

|𝑉LCC | , |𝑉𝑑 |

where 𝑉LCC is the vertex set of the largest weakly connected component in 𝐺𝑑 . This metric indicates how strongly the explored structure is concentrated in one main connected region. A larger LCC ratio suggests that most activated functions belong to a single dominant subsystem, whereas a smaller ratio suggests that execution is distributed across multiple disconnected or weakly connected regions. Number of Weakly Connected Components (#WCC). To measure fragmentation directly, we compute #WCC(𝐺𝑑 ) = number of weakly connected components in 𝐺𝑑 . This metric complements the LCC ratio. Whereas LCC shows how dominant the largest region is, #WCC shows how many distinct structural regions are activated in total. A larger value indicates more fragmented exploration, while a value of one indicates that all activated nodes belong to a single connected region. Together, these two metrics provide a clearer picture of structural cohesion than either alone. 3 Metric for internal community organization. To characterize whether the explored structure is internally organized

into distinct functional clusters, we measure modularity. Modularity (𝑄). Because the whole-program call graph and each driver-induced subgraph are directed, we measure internal community organization using directed modularity. Let 𝐴𝑖 𝑗 denote the adjacency matrix of 𝐺𝑑 , where 𝐴𝑖 𝑗 = 1 if there is a call edge from node 𝑖 to node 𝑗 and 𝐴𝑖 𝑗 = 0 otherwise. Let 𝑘𝑖out and 𝑘 in 𝑗 denote the out-degree of node 𝑖 and the in-degree of node 𝑗, respectively, and let 𝑐𝑖 denote the community assignment of node 𝑖. We compute directed modularity as: 𝑄 (𝐺𝑑 ) = Manuscript submitted to ACM

! 𝑘𝑖out𝑘 in 1 ∑︁ 𝑗 𝐴𝑖 𝑗 − 𝛿 (𝑐𝑖 , 𝑐 𝑗 ), |𝐸𝑑 | 𝑖,𝑗 |𝐸𝑑 |

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

15

where 𝛿 (·) is the Kronecker delta [23]. Community detection is performed using a Louvain-style heuristic that maximizes directed modularity [6, 18]. This metric captures an aspect of structural organization not reflected by size or connectivity alone. A larger modularity value indicates that the explored subgraph is organized into more distinct directed communities with sparser cross-community links, whereas a smaller value indicates weaker community structure. We include this metric because two drivers may cover similarly large subgraphs while differing substantially in how clearly their explored structure is partitioned into directed functional clusters. 4 Metrics for inter-driver redundancy and complementarity. To understand whether different drivers explore similar or

distinct structural regions, we measure pairwise overlap between their induced subgraphs. Inter-driver structural overlap. To quantify structural redundancy and complementarity across drivers, we compute pairwise intersection-over-union (IoU) between their induced subgraphs at both the function and call-edge levels: IoU𝑉 (𝑑𝑖 , 𝑑 𝑗 ) =

|𝑉𝑖 ∩ 𝑉𝑗 | , |𝑉𝑖 ∪ 𝑉𝑗 |

IoU𝐸 (𝑑𝑖 , 𝑑 𝑗 ) =

|𝐸𝑖 ∩ 𝐸 𝑗 | . |𝐸𝑖 ∪ 𝐸 𝑗 |

Here, IoU𝑉 measures the overlap between the function sets of drivers 𝑑𝑖 and 𝑑 𝑗 , while IoU𝐸 measures the overlap between their call-edge sets. A larger IoU value indicates that two drivers activate more similar structural regions, suggesting greater redundancy. A smaller IoU value indicates that the two drivers cover more distinct regions, suggesting greater complementarity. Function-level IoU captures overlap in activated functions, whereas edge-level IoU captures similarity in interprocedural execution structure. These metrics are useful because the benefit of multi-driver fuzzing depends not only on how much structure each driver covers individually, but also on how much new structure it contributes relative to other drivers. 5 Metrics for identifying under-explored structural regions. To support RQ5, we identify coarse-grained structural regions

that remain weakly explored after union multi-driver fuzzing. Structural regions. We partition the whole-program call graph into structural regions that serve as coarse-grained analysis units: R = CommunityDetect(𝐺) = {𝑅1, 𝑅2, . . . , 𝑅𝑘 }, where each region 𝑅𝑖 ⊆ 𝑉 is a densely connected directed cluster. In practice, we use a Louvain-style local-moving and aggregation heuristic adapted to maximize directed modularity [2, 5]. These regions are used only as structural analysis units for locating residual exploration gaps. Region coverage. Let 𝐶 union ⊆ 𝑉 denote the set of functions covered by union multi-driver fuzzing. For each structural region 𝑅𝑖 , we define |𝑅𝑖 ∩ 𝐶 union | . |𝑅𝑖 | This metric measures the fraction of functions in region 𝑅𝑖 that are reached by union multi-driver fuzzing. A smaller RC(𝑅𝑖 ) =

value indicates that the region remains less explored. Regions with lower coverage are treated as candidate residual gaps for later inspection. Together, these region-level metrics reveal whether fuzzing explores the program broadly or instead concentrates repeatedly on a limited structural core. This perspective is important because aggregate coverage alone cannot show whether the observed progress is evenly distributed across the program or confined to a small subset of regions.

4.6.2 RQ-Driven Evaluation. In Phase IV, we aggregate the fuzzing outcomes and structural measurements obtained in the previous phases to answer the research questions. The purpose of this phase is to connect the collected execution Manuscript submitted to ACM

16

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

profiles and driver-induced structural analyses to the empirical findings of the study. To this end, we organize the evaluation according to the role of each question. RQ1 examines overall multi-driver effectiveness by comparing union multi-driver results against individual-driver baselines using function coverage, control-flow edge coverage, and crashes. RQ2 evaluates whether fuzzing contributions are balanced across drivers by analyzing per-driver outcome distributions and normalized contributions under the shared execution policy. RQ3 characterizes the structural properties of driver-induced subgraphs using metrics such as size, connectedness, fragmentation, and modularity. RQ4 measures structural redundancy and complementarity across drivers using pairwise function-level and edge-level overlap. RQ5 identifies structural regions that remain under-explored after union multi-driver fuzzing using region coverage, and then uses representative case studies to investigate the causes of these residual exploration gaps. Organizing the evaluation in this way ensures that each research question is answered by the measurements most directly relevant to it. It also makes the connection between the study design and the reported findings explicit, improving the interpretability of the overall empirical analysis. 4.7

Tool Support

To implement the study pipeline, we develop two lightweight tool components, MFuzz and GDissert, as shown in Figure 4. MFuzz is the execution-side component. It extends Honggfuzz [47] with driver switching, shared-memorybased profile collection, and online projection of per-driver execution onto the shared structural backbone. GDissert is the analysis-side component. It consumes the driver-induced subgraphs produced by MFuzz and performs offline parsing, aggregation, and metric computation for the RQ-driven evaluation. This separation is intentional. MFuzz is responsible for controlled multi-driver execution and runtime artifact collection, whereas GDissert performs post hoc structural analysis. As a result, the analysis remains observational and does not introduce guidance or feedback into the fuzzing loop. Additional implementation details are provided in the artifact. MFUZZ

Driver Specifications

Driver Scheduler (round-robin)

Whole-program Call-Graph

Selected Driver

Fuzzing Engine (driver-switch enabled) GDissert Driver Call-Profile Driver-induced Structural Projection

Graph Parser Driver-Induced Subgraphs

Metric Analyzers RQ Results

Fig. 4. Tool support for the empirical study. MFuzz performs multi-driver fuzzing with driver switching and online profile collection. GDissert performs offline analysis of driver-induced subgraphs and computes the structural metrics used in the study.

4.7.1 MFuzz: Execution-side support. MFuzz is the execution-side implementation of the framework. It is built on top of honggfuzz [47] and extends the base fuzzing engine with multi-driver scheduling and online structural profiling. Its purpose is to execute multiple driver configurations within a single fuzzing instance while preserving strict attribution of runtime artifacts to the active driver. Given a total fuzzing budget 𝑇 and a driver set D, MFuzz implements round-robin driver scheduling with equal time slices. When a driver is selected, MFuzz applies its execution configuration, including command-line options and seed corpus, and switches the fuzzing engine to that configuration until the current time slice ends. To preserve driver attribution during execution, MFuzz maintains shared-memory coverage structures that are synchronized at driver-switch boundaries. During fuzzing, function- and call-edge coverage updates are recorded in the shared profile Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

17

together with the currently active driver identifier. At the end of each time slice, MFuzz snapshots the accumulated profile of the outgoing driver and projects the observed coverage onto the shared whole-program call graph. This step yields the driver-induced subgraph used in later structural analysis. Internally, driver attribution is represented through driver-indexed bitmaps attached to call-graph nodes and edges. A set bit indicates that the corresponding function or call edge has been observed under that driver in at least one execution during the current run. This representation keeps profiling and projection lightweight, supports efficient union and comparison across drivers, and avoids maintaining separate full graph copies for each driver. Using a unified fuzzing engine is an intentional implementation choice. It ensures that all drivers share the same mutation logic, instrumentation, scheduling framework, and runtime environment, reducing variance that would otherwise arise from launching fully independent fuzzing instances. At the same time, synchronized driver switching and shared-memory profiling preserve strict per-driver attribution of coverage and crashes. The implementation of MFuzz is lightweight, consisting of approximately 4KLoC lines of C/C++ code on top of honggfuzz [47]. 4.7.2 GDissert: Analysis-side support. GDissert is the analysis-side implementation of the framework. It operates offline on the structural artifacts produced by MFuzz, parses the resulting driver-induced subgraphs, and computes the measurements used in the RQ-driven evaluation. Implementation-wise, GDissert is organized into two stages. The first stage parses the whole-program call graph and the driver-induced subgraph artifacts emitted by MFuzz, reconstructing the per-driver structural views needed for analysis. The second stage applies the metric analyzers to compute the measurements used throughout the study, including subgraph size, connectivity, fragmentation, modularity, inter-driver overlap, and region coverage for identifying under-explored structural regions. These outputs support the quantitative analyses in RQ1–RQ5 and the selection of representative cases for analyzing residual exploration gaps. Because all measurements are computed with respect to the same whole-program call graph, the resulting structural properties are directly comparable across drivers and executables. The implementation of GDissert consists of approximately 2.8KLoC lines of Python code, excluding third-party parsing and analysis libraries. 4.7.3 Implementation Validation. Because MFuzz operates inside the fuzzing loop, we validate whether its driverswitching and profiling mechanisms materially affect fuzzing behavior or introduce substantial execution overhead. To make this validation both representative and conservative, we select one large executable per benchmark domain from Table 2, prioritizing targets with high function counts. This choice stresses the main cost drivers of MFuzz, since larger targets generally require more structural state to maintain and project during switching. At the same time, selecting one target from each domain preserves diversity across program classes, input formats, and execution structures. The resulting validation set consists of snort, ffprobe, git, pdftops, cppcheck, python, upx, and h5dump. Unless otherwise noted, all validation results are reported as averages over five independent runs. Coverage preservation under switching. To assess whether driver switching materially perturbs fuzzing outcomes, we compare pure single-driver fuzzing with honggfuzz [47] against round-robin execution in MFuzz over duplicated copies of the same driver configuration. For each target, we select the driver configuration that achieves the highest single-driver CFG-edge coverage in the single-driver baseline used for RQ1, and duplicate that same configuration in MFuzz. This avoids arbitrary option selection, aligns the validation with the paper’s primary baseline, and ensures that the tested configuration corresponds to a semantically meaningful execution mode already used in the benchmark suite. Since the duplicated drivers are semantically identical, any substantial difference in final coverage can be primarily attributed to the switching mechanism rather than to differences in execution mode. We report the final number of Manuscript submitted to ACM

18

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

covered CFG edges under the same fuzzing budget. For readability, Table 3 reports only the distinguishing driver options; the full commands, inputs, seed corpora, and auxiliary files are provided in the artifact. Small differences indicate that driver switching preserves the underlying coverage behavior of the fuzzing process. Table 3. CFG-edge coverage under driver switching for the validation targets. Reported values are averages over five independent runs. Relative difference is computed as (MFuzz − honggfuzz)/honggfuzz × 100. Executable

Selected Option

CFG Edges (MFuzz)

CFG Edges (honggfuzz)

Rel. Diff. (%)

snort ffprobe git pdftops cppcheck python upx h5dump

-c conf/min.lua -show_streams -i apply -level1 --enable=warning -x -q compress -n

7407 13070 533 2186 4113 18709 4958 5388

7464 12915 536 2228 4098 18604 4973 5407

-0.8% 1.2% -0.6% -1.9% 0.4% 0.6% -0.3% -0.4%

Table 3 shows that single-driver honggfuzz and round-robin execution in MFuzz produce highly similar coverage results on all eight validation targets. The relative difference ranges from −1.9% to +1.2%, and remains within 1% for six of the eight targets. Moreover, the differences are mixed in sign rather than consistently favoring either system, suggesting that they mainly reflect normal fuzzing variation rather than a systematic effect of driver switching. Overall, these results indicate that MFuzz preserves coverage behavior under switching with only minor deviation from pure single-driver fuzzing. Execution overhead. We next quantify the practical overhead introduced by MFuzz relative to base honggfuzz on the same validation targets. We report two measurements. First, we measure the average cost of a driver switch, including synchronization, profile snapshotting, and per-switch projection onto the whole-program call graph. Second, we report peak memory usage for both honggfuzz and MFuzz, together with their relative difference. Table 4. Execution overhead of MFuzz relative to honggfuzz on the validation targets. Reported values are averages over five independent runs. Relative memory difference is computed as (MFuzz − honggfuzz)/honggfuzz × 100. Executable

Avg. Switch Cost (ms)

Peak Mem. (MFuzz, MB)

Peak Mem. (honggfuzz, MB)

Rel. Diff. (%)

79.2 384.5 67.5 83.3 71.1 553.1 54.9 877.3

1019.7 14012.1 31.5 353.3 676.3 205.2 54.3 668.2

833.2 11728.4 23.1 277.3 612.6 178.3 46.8 513.5

22.4% 19.5% 36.4% 27.4% 10.4% 15.1% 16.0% 30.1%

snort ffprobe git pdftops cppcheck python upx h5dump

Table 4 shows that MFuzz consistently increases peak memory usage relative to honggfuzz, but the additional cost remains manageable for our empirical study. The peak memory cost is dominated by the retained corpus, particularly the number of preserved seeds and their sizes, whereas the in-memory profiling and graph-related state of MFuzz contributes a smaller fixed overhead for driver attribution and coverage projection. Accordingly, targets with larger or more rapidly growing corpora can exhibit a more noticeable memory gap. For example, on ffprobe, we observe a Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

19

substantially larger peak memory difference, which is consistent with a larger retained corpus: MFuzz preserves 193 more seeds, each averaging about 10 MB, in addition to the structural profiling overhead. For smaller benchmarks, the relative increase can appear high while the absolute cost remains low; for instance, git shows a 36.4% increase, but the absolute difference is only 8.4 MB. The switch-cost results show a similar pattern. Larger targets generally incur higher switching overhead, which is expected because profile snapshotting and coverage projection operate over larger structural states. Even the highest observed switch cost remains below 1 s, and switching occurs only at driver-slice boundaries rather than per test case, so this cost is amortized over the entire execution slice. Overall, these results indicate that MFuzz preserves coverage behavior under driver switching while introducing manageable runtime and memory overhead on large representative targets from different benchmark domains. This supports the use of MFuzz as lightweight execution support for the empirical study.

5

Empirical Results

This section presents the empirical results for the study goals and research questions in Section 3 using the methodology described in Section 4. All graph-based results are derived from driver-induced subgraphs projected onto the wholeprogram call-graph backbone and are computed using the variables and metrics defined in Section 4.6.1. Experimental Environment. All experiments were conducted on a 64-bit Ubuntu 18.04 workstation equipped with a 24-core AMD Ryzen Threadripper 7960X CPU and 128 GB of RAM. Each fuzzing instance was pinned to a dedicated CPU core and executed for 24 hours. To reduce the effect of fuzzing nondeterminism, each experiment was repeated five times. Experimental Protocol. For each benchmark executable and its associated drivers, we run fuzzing under the controlled driver-switching setup described in Section 4.7, ensuring consistent instrumentation, mutation policies, and runtime conditions across drivers. The total fuzzing budget is divided evenly across drivers, and dynamic profiles are synchronized only at driver-switch boundaries to preserve correct per-driver attribution of function coverage and crash artifacts. All structural measurements are computed offline from the collected profiles, without introducing any feedback into the fuzzing process. Since fuzzing is nondeterministic, repeated runs of the same executable may produce slightly different coverage outcomes and induced structural subgraphs. For scalar fuzzing outcomes, function coverage and crashes are attributed to individual drivers and reported as averages across the five runs. In contrast, CFG edge coverage is reported only at the executable level and is not distinguished by driver. For graph-based structural analysis, we aggregate repeated runs of the same driver by taking the union of their covered functions and call edges on the shared whole-program call graph. All structural metrics are then computed on these aggregated driver-induced subgraphs, yielding a more stable representation of the structure explored by each driver.

5.1

RQ1: Effectiveness of Fuzzing with Multi-driver

RQ1 examines overall fuzzing effectiveness by comparing MFuzz with MFuzz-single (the best individual-driver configuration) under the same total fuzzing budget. We evaluate coverage effectiveness using function-level coverage on the shared call-graph backbone and final CFG-edge coverage, and we additionally report bug-finding outcomes exposed by MFuzz. This allows us to assess whether combining drivers in MFuzz improves structural exploration over the strongest single-driver configuration while also exposing practically meaningful failures. Manuscript submitted to ACM

20

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

Table 5. Coverage results comparing MFuzz and MFuzz-single under the same total fuzzing budget, in terms of covered call-graph nodes (#CGNode) and control-flow graph edges (#CFGEdge). Delta shows the relative improvement of MFuzz over MFuzz-single. MFuzz Benchmark snort3 unbound http-parser ffmpeg libtiff

wavpack git sleuthkit file xpdf libxml2 jq binutils cppcheck libdwarf cpython3 quickjs lua libarchive upx xz hdf5

netcdf sqlite3

Executable snort snort2lua unbound-checkconf parsertrace url_parser ffmpeg ffprobe tiff2bw tiffinfo tiff2pdf wavpack wvunpack wvgain git istat img_stat tsk_recover file pdfdetach pdfinfo pdftops xmllint jq objdump readelf addr2line cppcheck dwarfdump python qjs qjsc lua bsdtar bsdunzip upx xz h5dump h5ls h5repack ncdump ncgen nccopy sqlite3

MFuzz-single

Delta

#𝐷𝑟𝑖𝑣𝑒𝑟

#𝐶𝐺𝑁 𝑜𝑑𝑒

#𝐶𝐹𝐺𝐸𝑑𝑔𝑒

#𝐶𝐺𝑁 𝑜𝑑𝑒

#𝐶𝐹𝐺𝐸𝑑𝑔𝑒

#𝐶𝐺𝑁 𝑜𝑑𝑒

#𝐶𝐹𝐺𝐸𝑑𝑔𝑒

9 10 7 3 2 19 28 7 7 21 32 30 12 6 4 7 4 12 12 25 66 40 18 22 29 8 48 29 23 6 27 36 15 13 22 17 12 12 37 17 22 30 48

8394 1924 62 14 5 1423 2415 198 274 315 16 14 15 222 74 174 74 176 317 368 744 657 390 919 301 392 1763 376 3948 944 639 985 493 240 1914 232 1860 1765 2298 443 248 17 392

9509 4121 340 369 23 5990 13361 1275 1804 2233 128 106 71 549 89 129 89 1468 1310 1572 2947 5586 1876 7885 4595 2572 4526 1294 21062 8398 6966 4957 2129 1394 5019 789 8472 7998 10076 1922 348 67 2536

6359 1884 61 12 4 1178 2273 163 271 295 15 11 12 216 66 168 66 134 322 354 670 499 354 627 184 368 1745 324 3652 689 637 250 502 176 1914 216 1257 1676 2183 369 66 14 392

7464 3764 271 213 14 3816 12915 576 1788 1985 68 49 41 536 77 111 77 483 1356 1318 2228 3570 1554 3906 2366 2265 4098 1232 18604 1784 6943 563 3160 888 4973 246 5407 7656 9608 1388 120 24 2536

32.0% 2.1% 1.6% 16.7% 25.0% 20.8% 6.2% 21.5% 1.1% 6.8% 6.7% 27.3% 25.0% 2.8% 12.1% 3.6% 12.1% 31.3% -1.6% 4.0% 11.0% 31.7% 10.2% 46.6% 63.6% 6.5% 1.0% 16.0% 8.1% 37.0% 0.3% 294.0% -1.8% 36.4% 0.0% 7.4% 48.0% 5.3% 5.3% 20.1% 275.8% 21.4% 0.0%

27.4% 9.5% 25.5% 73.2% 64.3% 57.0% 3.5% 121.4% 0.9% 12.5% 88.2% 116.3% 73.2% 2.4% 15.6% 16.2% 15.6% 203.9% -3.4% 19.3% 32.3% 56.5% 20.7% 101.9% 94.2% 13.6% 10.4% 5.0% 13.2% 370.7% 0.3% 780.5% -32.6% 57.0% 0.9% 220.7% 56.7% 4.5% 4.9% 38.5% 190.0% 179.2% 0.0%

Average

27.9%

73.5%

5.1.1 Coverage Effectiveness. Table 5 compares MFuzz with MFuzz-single under the same total fuzzing budget. Effectiveness is evaluated using two structural coverage metrics: covered call-graph nodes (#CGNode) and covered control-flow graph edges (#CFGEdge). Overall, MFuzz improves structural exploration for most executables. Across the benchmark suite, it increases coverage by an average of 27.9% in #CGNode and 73.5% in #CFGEdge. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

21

For most executables, improvements are observed in both #CGNode and #CFGEdge, indicating that multi-driver fuzzing not only reaches more functions but also explores more intra-procedural control flow within the reached regions. Representative examples include ffmpeg (+20.8% in #CGNode, +57.0% in #CFGEdge), libxml2/xmllint (+31.7%, +56.5%), cpython3/python (+8.1%, +13.2%), and netcdf/ncdump (+20.1%, +38.5%). These consistent improvements suggest that different drivers expose complementary execution regions rather than repeatedly exercising the same structural areas. The gains are often substantially larger for #CFGEdge than for #CGNode. This pattern can be seen in file (+31.3% in #CGNode, +203.9% in #CFGEdge), quickjs/qjs (+37.0%, +370.7%), xz (+7.4%, +220.7%), and binutils/objdump (+46.6%, +101.9%). Such cases indicate that multi-driver fuzzing not only expands the set of reached functions, but also deepens exploration within already reached regions by activating additional control-flow alternatives. This asymmetry is important because it shows that driver diversity can improve both breadth and depth of structural exploration. Several executables exhibit especially large gains, indicating strong complementarity among drivers. For example, lua improves by +294.0% in #CGNode and +780.5% in #CFGEdge, while netcdf/ncgen improves by +275.8% and +190.0%. Similarly, hdf5/h5dump shows gains of (+48.0%, +56.7%), and binutils/readelf improves by (+63.6%, +94.2%). These cases suggest that single-driver fuzzing leaves substantial executable-specific regions unexplored, whereas combining multiple drivers covers substantially larger portions of the software structure. The magnitude of improvement is nevertheless uneven across executables. Some cases show only marginal gains, including cppcheck/cppcheck (+1.0%, +10.4%), quickjs/qjsc (+0.3%, +0.3%), git (+2.8%, +2.4%), and libtiff/tiffinfo (+1.1%, +0.9%). These small deltas suggest that the corresponding drivers are likely to be highly overlapping or otherwise structurally redundant, so additional drivers contribute little new structure beyond the strongest individual one. This interpretation is consistent with the low-dispersion cases reported in RQ2 (Section 5.2) and the higher-overlap patterns analyzed in RQ4 (Section 5.4). A small number of executables show slight regressions under multi-driver fuzzing, notably xpdf/pdfdetach (−1.6%, −3.4%) and libarchive/bsdtar (−1.8%, −32.6%). These are exceptions rather than the dominant trend. Under a fixed total budget, distributing effort across multiple drivers can reduce the time allocated to a particularly effective single driver, especially when drivers overlap heavily or when one driver dominates exploration. This behavior is consistent with the driver-imbalance results in RQ2. Near-parity appears only in a few cases, such as sqlite3 (0.0%, 0.0%) and upx (0.0%, +0.9%). These results suggest that some programs have highly shared execution backbones across drivers, so multi-driver fuzzing offers little additional structural benefit. As shown later in RQ2 and RQ4, such cases are associated with low driver heterogeneity and high structural redundancy. 5.1.2 Bug Discovery. Table 6 shows that the structural gains of MFuzz also lead to practically meaningful defect-finding results. In total, MFuzz exposed 13 unique bugs and abnormal behaviors across four benchmarks. These findings are concentrated in a small set of executables and driver combinations, suggesting that bug exposure is strongly dependent on execution mode. Among the 13 findings, only 3 are also marked as reachable by MFuzz-single, while the remaining majority are exposed only when multiple drivers are combined in MFuzz. The findings also span different severity and maturity levels, including newly submitted bugs in ncdump, confirmed known abnormal behaviors in h5repack and readelf, and a pending hang in lua. Overall, this shows that the benefit of MFuzz is not limited to improving aggregate structural coverage, but also includes exposing failure behaviors that remain hidden under the strongest single-driver configuration. The findings are also closely tied to semantically specialized execution modes rather than generic default behavior. In ncdump, the exposed bugs are triggered by formatting and extraction-related options. In h5repack, they cluster around ordering and transformation modes. In readelf, they arise under debug-display and whole-file reporting Manuscript submitted to ACM

22

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

Table 6. Unique bugs and abnormal behaviors exposed by MFuzz, totaling 11 findings. Findings marked with † were also exposed by MFuzz-single, totaling 3. Detailed per-bug reports are provided in the artifact. Benchmark

Executable

Netcdf

ncdump

Netcdf

ncdump

HDF5

h5repack

Binutils Binutils Lua

readelf readelf lua

Triggering driver(s) -i -b f -c -x -n -q name -q creation_order -z ascending -w all -a -E

Exposed bug(s)

Known?

Status

1× Assertion; 2 × Heap corruptions

Unknown

Issue submitted

1 × Double free†

Unknown

Issue submitted

2 × Double Free; 2 × Heap Corruption

Known

Confirmed

1 × SIGABRT 1 × SIGABRT† 1 × Hang†

Known Known Unknown

Confirmed Confirmed Pending

modes, while in lua the hang appears under the -E execution mode. These are not merely arbitrary command-line variations. Instead, they activate different semantic slices of the same executable and therefore exercise different parsing, output, transformation, cleanup, and error-handling paths. This helps explain why many findings are not recovered by MFuzz-single even when that configuration is the strongest one overall: higher aggregate coverage does not necessarily provide access to the specific semantic modes in which these failures occur. Taken together, these results indicate that bug discovery in configuration-rich executables is driver-sensitive in much the same way as structural exploration. They therefore reinforce the main conclusion of RQ1: combining drivers in MFuzz is beneficial not only because it broadens structural reach, but also because it exposes semantically distinct execution behaviors that can uncover bugs and abnormal states missed by the best single-driver configuration. More broadly, the results suggest that driver-aware fuzzing should preserve execution-mode diversity rather than collapsing effort onto a single dominant driver, since rare or specialized modes may contribute disproportionately to bug exposure despite accounting for only a limited share of overall coverage. MFuzz is generally more effective than MFuzz-single under the same total fuzzing budget. Across the benchmark suite, it improves coverage by an average of 27.9% in call-graph nodes and 73.5% in control-flow graph edges, showing gains in both the breadth and depth of structural exploration. Beyond coverage, MFuzz also exposed 13 unique bugs and abnormal behaviors, only 3 of which were also found by MFuzz-single. These results show that combining drivers in MFuzz improves not only structural reachability, but also practical bug discovery by exercising semantic behaviors that the strongest single-driver configuration does not reliably reach. 5.2

RQ2: Driver Effectiveness Under Equal Time Budgets

To evaluate driver effectiveness under equal time budgets, we use call-graph node coverage (#CGNode) as a measure of function-level structural activation. For each executable, a driver’s effectiveness is represented by its normalized coverage share with respect to the overlap-aware union of covered call-graph nodes across all drivers. Under identical fuzzing time for each driver, Table 7 summarizes the distribution of these normalized per-driver coverage shares using standard deviation (Std), coefficient of variation (CV), and Min/Median/Max values. Across the benchmark suite, driver effectiveness under equal time budgets exhibits substantial dispersion and wide variability. The coefficient of variation (CV) ranges from 0 to above 2.7. For example, sqlite3 shows CV = 0, indicating Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

23

Table 7. Dispersion of normalized per-driver call-graph node coverage under equal time budgets. #𝐷𝑟𝑖𝑣𝑒𝑟 denotes the number of drivers, and #𝐶𝐺𝑁 𝑜𝑑𝑒 denotes the overlap-aware union of covered call-graph nodes across all drivers. Std, CV, and Min/Median/Max summarize the distribution of normalized per-driver coverage shares.

Benchmark snort3 unbound http-parser ffmpeg libtiff

wavpack git sleuthkit file xpdf libxml2 jq binutils cppcheck libdwarf cpython3 quickjs lua libarchive upx xz hdf5

netcdf sqlite3

Executable

#𝐷𝑟𝑖𝑣𝑒𝑟

#𝐶𝐺𝑁 𝑜𝑑𝑒

Std

CV

Min

Median

Max

snort snort2lua checkconf parsertrace url_parser ffmpeg ffprobe tiff2bw tiffinfo tiff2pdf wavpack wvunpack wvgain git istat img_stat tsk_recover file pdfdetach pdfinfo pdftops xmllint jq objdump readelf addr2line cppcheck dwarfdump python qjs qjsc lua bsdtar bsdunzip upx xz h5dump h5ls h5repack ncdump ncgen nccopy sqlite3

9 10 7 3 2 19 28 7 7 21 32 30 12 6 4 7 4 12 12 25 66 40 18 22 29 8 48 29 23 6 27 36 15 13 22 17 12 12 37 17 22 30 48

8394 1924 62 14 5 1423 2415 198 274 315 16 14 15 222 74 174 74 176 317 368 744 657 390 919 301 392 1763 376 3948 944 639 985 493 240 1914 232 1860 1765 2298 443 248 17 392

0.0786 0.0433 0.3386 0.0673 0.1000 0.3388 0.3812 0.4774 0.0866 0.0112 0.1954 0.0878 0.1499 0.1528 0.0147 0.4634 0.0147 0.2228 0.3639 0.3480 0.3418 0.2327 0.3193 0.1527 0.1381 0.4591 0.0657 0.0456 0.2889 0.2281 0.3087 0.2479 0.2867 0.0851 0.0006 0.0901 0.0981 0.0828 0.3356 0.3396 0.4149 0.0957 0.0000

0.1133 0.0446 0.3930 0.0707 0.1111 1.6137 1.2437 0.8354 0.1051 0.0119 0.2387 0.1142 0.1984 0.1689 0.0161 0.8275 0.0161 0.7295 2.0031 2.0364 2.2620 0.5020 0.8563 0.3535 0.4129 0.7310 0.0748 0.0638 0.3792 0.2686 2.7118 0.5783 2.1396 0.0951 0.0006 0.2159 0.1065 0.1108 0.6464 0.6099 0.6731 0.3938 0.0000

0.5825 0.8540 0.0323 0.8571 0.8000 0.0632 0.0207 0.0152 0.7664 0.9206 0.5000 0.4286 0.2667 0.5631 0.8919 0.0172 0.8919 0.1591 0.0189 0.0190 0.0067 0.0091 0.0462 0.1055 0.2492 0.0353 0.8395 0.6782 0.0251 0.3485 0.0047 0.2538 0.0203 0.7417 0.9974 0.2269 0.6742 0.5711 0.2215 0.0045 0.1212 0.1765 1.0000

0.6748 0.9923 1.0000 1.0000 0.9000 0.0632 0.0253 0.9848 0.7701 0.9397 0.9375 0.7857 0.8000 0.9730 0.9189 0.9598 0.9189 0.2216 0.0189 0.0190 0.0067 0.5495 0.3051 0.3645 0.2757 0.9810 0.8395 0.7021 0.8528 0.9550 0.0047 0.3066 0.0203 0.9375 0.9990 0.3935 0.9710 0.7331 0.2293 0.6456 0.9697 0.2353 1.0000

0.8764 1.0000 1.0000 1.0000 1.0000 0.9958 0.9213 0.9848 0.9818 0.9778 1.0000 0.8571 0.8667 0.9730 0.9324 0.9655 0.9324 0.9489 0.9968 0.9864 0.9772 0.7458 0.9564 0.8020 0.8339 0.9891 0.9977 0.8723 0.9620 0.9894 0.9937 0.9939 0.9026 0.9583 1.0000 0.6204 0.9871 0.9416 0.9386 0.9165 1.0000 0.6471 1.0000

Manuscript submitted to ACM

24

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

perfectly uniform contribution across its 48 drivers, whereas qjsc exhibits CV = 2.71, reflecting extreme imbalance. This wide range shows that equal scheduling does not systematically produce equal structural contribution. A recurring pattern is pronounced right-skewness in the distribution of effectiveness shares. In many executables, minimum shares approach zero while maximum shares approach one. For example, pdftops (66 drivers) has Min = 0.0067 and Max = 0.9772, while ffmpeg has Min = 0.0632 and Max = 0.9958. Median values are often substantially lower than the maximum, indicating that structural activation is concentrated in a small subset of drivers. In extreme cases, one driver dominates exploration while several others contribute negligibly. This dominant-driver pattern is especially visible in qjsc and bsdtar, where the maximum share is close to 1 but the median remains close to zero. In contrast, near-uniform contribution is rare and appears only in a small subset of executables, such as sqlite3 and upx, where Min/Median/Max values are tightly clustered around 1 and CV is nearly zero. In these cases, drivers activate almost identical structural regions, suggesting that configuration options largely share a common execution backbone. This observation is consistent with the near-parity cases in RQ1 (Section 5.1), where multi-driver fuzzing provides little additional benefit over the best single driver. Most executables lie between these extremes and exhibit moderate dispersion. For example, wavpack (CV = 0.24) and h5ls (CV = 0.11) show noticeable but not dominant imbalance. In such cases, drivers differ meaningfully in effectiveness, but no single driver fully dominates exploration. Even in these intermediate cases, structural contribution remains uneven, indicating that heterogeneity is not confined to a few extreme outliers but is a systematic property of driver-based execution. This dispersion pattern appears across multiple software domains, including media tools (ffmpeg), document processors (xpdf), language runtimes (quickjs), and storage systems (sqlite3). The consistency of this pattern across domains suggests that effectiveness heterogeneity is not specific to a particular workload class, but reflects a broader structural property of configuration-driven software. These results also help explain the effectiveness differences observed in RQ1. Executables with highly imbalanced driver contributions are more likely to benefit from multi-driver fuzzing when distinct drivers expose complementary structural regions, but they may also suffer from redundant budget allocation when many weak drivers overlap with a dominant one. Conversely, near-uniform cases such as sqlite3 and upx indicate strong redundancy across drivers, which explains why multi-driver fuzzing offers little additional structural gain in those executables.

Driver effectiveness under equal time budgets is systematically heterogeneous. While a small subset of programs exhibits near-uniform contribution, most executables demonstrate moderate to strong imbalance, and several show dominantdriver behavior in which a few drivers account for most structural activation. Equal resource allocation therefore does not guarantee balanced exploration across configuration space, which helps explain why round-robin multi-driver fuzzing can be effective in some executables but inefficient in others.

5.3

RQ3: Structural Organization and Modularity

We answer RQ3 by analyzing the structural organization of driver-induced subgraphs within the whole-program call graph. All measurements are performed on driver-induced subgraphs using the shared whole-program call graph as a common structural reference, enabling direct comparison across drivers and executables. For each driver, we evaluate three graph-level properties: Largest Connected Component (LCC) ratio for cohesion, Number of Weakly Connected Components (#WCC) for fragmentation, and modularity (𝑄) for community structure. Figure 5 summarizes the per-driver distributions of these metrics across executables. Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

pdftops pdfinfo pdfdetach wvunpack wvgain wavpack qjsc ncgen nccopy dwarfdump bsdtar url_parser parsertrace file tiffinfo tiff2bw h5repack img_stat tiff2pdf ncdump readelf jq qjs checkconf objdump xmllint git addr2line h5ls h5dump lua upx xz sqlite3 ffmpeg ffprobe python cppcheck bsdunzip snort2lua snort tsk_recover istat 0.0

(a) Cohesion (LCC ratio)

0.2

0.4 0.6 LCC ratio

0.8

25

(b) Fragmentation (#WCC)

1.0

0

1000 2000 #WCC

3000 0.0

(c) Modularity (Q)

0.2

0.4 0.6 0.8 Modularity Q

1.0

Fig. 5. Structural organization of driver-induced subgraphs across executables. Boxplots summarize per-driver distributions for each executable. (a) Largest Connected Component (LCC) ratio measures cohesion. (b) Number of Weakly Connected Components (#WCC) measures fragmentation. (c) Modularity (𝑄) measures community structure. Executables are ordered by median LCC ratio. The results show substantial structural variation across drivers for many programs (e.g., ffmpeg, quickjs, libxml2), while others (e.g., sqlite3, upx) remain consistently cohesive, indicating that configuration modes can either concentrate execution within unified regions or activate structurally distinct subsystems.

Manuscript submitted to ACM

26

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

5.3.1 Cohesion (LCC Ratio). Figure 5(a) reports the per-driver distribution of LCC ratios across executables. Across the benchmark suite, LCC ratios span a wide range, from approximately 0.15 to 1.0. Many executables exhibit substantial within-executable variation, with some drivers concentrated near a single cohesive region and others spread across multiple structural regions. For example, snort includes drivers with LCC ratios below 0.3 and others above 0.9, while ffmpeg spans roughly 0.3 to near 1.0. In contrast, sqlite3 and upx remain tightly concentrated near 1.0 across drivers. These results indicate that configuration modes often activate structurally distinct regions within the same executable: high-LCC drivers remain concentrated in a dominant connected region, whereas low-LCC drivers are distributed across multiple weaker components. This variation is consistent with the effectiveness differences observed in RQ1 (Section 5.1) and RQ2 (Section 5.2). Executables with consistently high LCC ratios across drivers, such as sqlite3 and upx, also showed near-parity in RQ1 and near-uniform contribution in RQ2, suggesting that their drivers largely traverse a shared structural core. By contrast, executables with wide LCC dispersion, such as ffmpeg and snort, are more consistent with heterogeneous driver behavior. Driver-induced subgraphs exhibit substantial variation in structural cohesion. While a small subset of executables remains consistently cohesive across drivers, most programs show wide dispersion in LCC ratios, indicating that configuration modes often activate structurally distinct execution regions within the same executable. 5.3.2 Fragmentation (#WCC). Figure 5(b) shows the per-driver distribution of weakly connected component counts (#WCC). Across the benchmark suite, #WCC ranges from 1 to above 20. Many executables show strong within-executable variation: some drivers induce a single connected component, whereas others activate many disconnected structural regions. For example, snort includes drivers whose #WCC exceeds 15, while others remain near 1. Similarly, ffmpeg and python show drivers with markedly larger component counts than their medians. In contrast, sqlite3 and upx remain tightly concentrated at #WCC = 1 across drivers. These results complement the LCC analysis. Drivers with higher fragmentation tend to activate multiple structurally disjoint subsystems, whereas low-#WCC drivers remain confined to a single cohesive region. This supports the view that configuration options can selectively enable independent feature modules or specialized processing pipelines. It also helps explain why equal driver budgets in RQ2 (Section 5.2) do not imply equal structural contribution: drivers that reach more fragmented regions may expose structural areas that other drivers do not cover. Driver-induced subgraphs exhibit substantial variation in structural fragmentation. While some executables maintain consistently connected subgraphs, many show heavy-tailed dispersion in #WCC, indicating that certain drivers activate multiple disjoint structural regions. Configuration modes therefore differ substantially in how they partition execution structure. 5.3.3 Modularity (𝑄). Figure 5(c) presents the per-driver distribution of modularity scores (𝑄). Across the benchmark suite, modularity values range from near 0 to above 0.6. Many executables show wide within-executable dispersion, with some drivers exhibiting weak community structure and others showing much stronger separation into structural clusters. For example, ffmpeg includes drivers with 𝑄 near 0.1 and others above 0.5. Similarly, qjsc and pdftops exhibit broad modularity ranges across drivers. In contrast, sqlite3 and upx remain tightly clustered at low 𝑄 values. Higher modularity is consistent with drivers activating more clearly separated functional communities, whereas lower modularity indicates more homogeneous structural interaction. Together with the LCC and #WCC results, this Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

27

shows that driver-induced subgraphs vary not only in size or overlap, but also in how their internal structure is organized. This structural variation provides a graph-level explanation for the heterogeneous effectiveness observed in RQ2 (Section 5.2) and anticipates the overlap patterns analyzed in RQ4 (Section 5.4).

Driver-induced subgraphs differ substantially in community organization. While some executables exhibit consistently low modularity, many show wide dispersion in 𝑄 values, indicating that configuration modes can selectively activate distinct functional communities. Structural organization therefore varies systematically across drivers.

5.4

RQ4: Driver Overlap and Redundancy

To evaluate structural redundancy among execution modes, we measure pairwise structural overlap between driverinduced subgraphs within the same executable. Overlap is quantified using intersection-over-union (IoU) over activated call-graph node sets (IoU𝑉 ) and activated call-graph edge sets (IoU𝐸 ). Each executable is therefore characterized by the distribution of IoU values computed across all driver pairs. Figure 6 summarizes these per-executable distributions, ordered by median IoU𝑉 in ascending order. Across the benchmark suite, structural overlap spans nearly the full range from 0 to 1. Some executables exhibit consistently low pairwise overlap, indicating that different drivers activate largely distinct structural regions. For example, img_stat, addr2line, tiff2bw, and ncdump show median IoU𝑉 values close to zero, with most driver pairs sharing little of the call graph. These cases suggest that the corresponding configuration modes map to relatively independent subsystems. At the other extreme, executables such as snort2lua, tiffinfo, h5dump, and upx show median IoU𝑉 values above 0.8 with compact interquartile ranges near 1. In these programs, different drivers activate highly similar structural regions, indicating substantial redundancy across execution modes. Most executables lie between these extremes and exhibit moderate overlap with substantial dispersion. Examples include ffmpeg, readelf, objdump, jq, and python, whose median IoU𝑉 values fall roughly between 0.4 and 0.7 and whose interquartile ranges remain wide. These distributions indicate that redundant and orthogonal driver pairs often coexist within the same executable. Some drivers traverse highly similar structural regions, whereas others activate relatively distinct portions of the call graph. This mixed-overlap pattern suggests that configuration spaces often contain multiple structural families rather than forming either a purely redundant or a purely orthogonal set of execution modes. Several executables show especially broad overlap ranges, with IoU values extending from near zero to near one. For example, pdftops and xmllint span almost the full overlap range across driver pairs. Such cases suggest that configuration spaces can decompose into groups of closely related drivers that coexist with more specialized drivers activating orthogonal subsystems. This clustering behavior provides a structural explanation for the heterogeneous driver effectiveness observed in RQ2 and helps explain why multi-driver fuzzing in RQ1 can yield large gains even when some drivers are individually redundant. Node-level and edge-level overlap follow broadly consistent trends, although edge overlap (IoU𝐸 ) is often more concentrated near the upper bound. In highly redundant executables such as snort2lua and upx, IoU𝐸 frequently approaches 1, indicating that drivers not only activate similar function sets but also preserve nearly identical caller– callee relationships. By contrast, executables such as ffmpeg and python often show moderate IoU𝑉 together with wider dispersion in IoU𝐸 . This suggests that drivers may activate overlapping functional regions while still inducing different interprocedural connectivity patterns within those regions. Configuration therefore influences not only which functions are activated, but also how those functions are structurally connected. Manuscript submitted to ACM

28

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

pdftops pdfinfo pdfdetach wvunpack wavpack checkconf sqlite3 qjsc git ffmpeg cppcheck upx h5ls h5dump tiff2pdf snort2lua tiffinfo dwarfdump tsk_recover istat python wvgain bsdunzip qjs parsertrace url_parser xmllint readelf nccopy bsdtar snort xz ffprobe objdump lua ncdump file jq h5repack ncgen addr2line tiff2bw img_stat 0.0

(a) Node overlap (IoUV)

0.2

0.4

IoUV

0.6

0.8

(b) Edge overlap (IoUE)

1.0 0.0

0.2

0.4

IoUE

0.6

0.8

1.0

Fig. 6. Distribution of pairwise structural overlap among driver-induced subgraphs. Each horizontal boxplot summarizes intersectionover-union (IoU) values computed between all driver pairs within the same executable. Panel (a) reports node-level overlap (IoU𝑉 ), and panel (b) reports edge-level overlap (IoU𝐸 ). Executables are ordered by median IoU𝑉 in ascending order. The dashed vertical line at 0.5 indicates moderate structural overlap.

Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

29

These overlap patterns are consistent with the earlier RQs. Executables with high redundancy, such as sqlite3 and upx, also showed near-uniform driver contribution in RQ2 and little improvement in RQ1, indicating that multiple drivers largely traverse the same shared structural core. Conversely, executables with broader overlap dispersion, such as ffmpeg, objdump, and python, are more consistent with the heterogeneous effectiveness patterns in RQ2 and the larger multi-driver gains observed in RQ1. The consistency of these patterns across media tools, document processors, toolchain utilities, language runtimes, and storage systems suggests that structural redundancy is not workload-specific, but a broader property of configuration-driven software. Driver-induced subgraphs exhibit highly heterogeneous structural overlap. Some executables show strong structural diversity, where most driver pairs activate largely disjoint call-graph regions, while others show substantial redundancy, with most drivers traversing nearly identical structural cores. Many programs also contain mixed overlap structure, where highly overlapping and weakly overlapping driver pairs coexist within the same executable. Node-level and edge-level overlap follow consistent overall trends, with edge overlap often more tightly concentrated near the upper bound. Structural overlap therefore varies systematically across programs and provides a graph-level explanation for both the effectiveness heterogeneity in RQ2 and the multi-driver gains observed in RQ1.

5.5

RQ5: Structural Under-Exploration in Multi-Driver Fuzzing

We next examine which structural regions remain under-explored after round-robin multi-driver fuzzing. Our analysis proceeds in two stages. First, we summarize residual region coverage over the shared structural backbone of each executable and group executables into recurring residual-gap categories based on the severity and shape of their remaining coverage gaps. We then use representative case studies from each category to explain why these regions remain difficult to explore. Table 8 reports the per-executable residual-coverage summaries used in this analysis. 5.5.1 Pattern Summary and Category Construction. Across the benchmark suite, residual region coverage spans a broad range. Some executables retain severe structural gaps after fuzzing, with median region coverage equal to zero and large fractions of regions remaining uncovered or only weakly covered. For example, ffmpeg, ffprobe, git, istat, tsk_recover, cppcheck, ncgen, nccopy, and checkconf all show RC-Median values of zero together with high Frac(𝑟𝑐 = 0) and Frac(𝑟𝑐 ≤ 0.5) values. In these executables, under-exploration is not limited to a small hard tail. Instead, a substantial portion of the shared structural backbone remains untouched or only marginally exercised. We group these executables into a category of backbone-dominated residual gaps. This category is meaningful because the dominant pattern is a large residual region mass rather than a few isolated hard regions. Such profiles indicate that equal time sharing across the available drivers is insufficient to activate much of the executable’s structural space, suggesting stronger access constraints such as driver-entry mismatch, format-specific logic, deeper semantic preconditions, or subsystems that are only weakly exercised by the current seed and scheduling setup. A second group of executables exhibits a different pattern. These programs achieve nontrivial structural exploration, but still leave a broad low-coverage tail across the backbone. Examples include objdump, readelf, addr2line, xmllint, python, xz, bsdtar, pdftops, pdfinfo, and pdfdetach. Their RC-Median values are above zero, indicating that fuzzing reaches a meaningful portion of the structural space, yet their Frac(𝑟𝑐 ≤ 0.5) values remain substantial, showing that many regions are still only weakly explored. We group these executables into a category of partial exploration with a substantial residual tail. Unlike the first category, these programs do not exhibit broad structural failure. However, unlike the strongest executables, their residual under-exploration is still structurally diffuse rather than localized. This Manuscript submitted to ACM

30

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

Table 8. Residual region coverage after round-robin multi-driver fuzzing. #𝑅𝑒𝑔𝑖𝑜𝑛 denotes the number of structural regions in the shared backbone. RC-Min, RC-Median, and RC-Max summarize the distribution of per-region coverage ratios (𝑟𝑐). Frac(𝑟𝑐 = 0), Frac(𝑟𝑐 ≤ 0.2), and Frac(𝑟𝑐 ≤ 0.5) report the fraction of regions that remain uncovered or weakly covered after fuzzing. Benchmark snort3 http-parser ffmpeg libtiff

wavpack git sleuthkit file xpdf libxml2 jq binutils cppcheck libdwarf cpython3 quickjs lua libarchive upx xz hdf5

netcdf sqlite3 unbound

Executable

#𝑅𝑒𝑔𝑖𝑜𝑛

RC-Min

RC-Median

RC-Max

Frac(𝑟𝑐 = 0)

Frac(𝑟𝑐 ≤ 0.2)

Frac(𝑟𝑐 ≤ 0.5)

snort snort2lua parsertrace url_parser ffmpeg ffprobe tiff2bw tiffinfo tiff2pdf wavpack wvunpack wvgain git istat img_stat tsk_recover file pdfdetach pdfinfo pdftops xmllint jq objdump readelf addr2line cppcheck dwarfdump python qjs qjsc lua bsdtar bsdunzip upx xz h5dump h5ls h5repack ncdump ncgen nccopy sqlite3 checkconf

87 24 1 1 198 139 8 6 8 10 8 5 39 64 14 59 13 10 10 17 13 14 22 21 16 89 17 33 14 13 10 20 9 27 14 10 9 8 12 10 11 7 18

0.0000 0.1000 1.0000 0.7143 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.1500 0.1579 0.0000 0.0000 0.0949 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.7692 0.0000 0.3030 0.0000 0.0000 0.0000 0.1765 0.0000 0.0000 0.0000 0.0000 0.0197 0.0000

0.0000 0.7042 1.0000 0.7143 0.0000 0.0000 0.4288 0.4207 0.3472 0.0000 0.0000 0.0000 0.0000 0.0000 0.6833 0.0000 0.6111 0.4243 0.4127 0.4444 0.2500 0.7510 0.1662 0.0270 0.0913 0.0000 0.1656 0.2439 0.4585 0.3361 0.9393 0.0933 0.8235 0.7918 0.1804 0.4002 0.3846 0.5328 0.3046 0.0000 0.0000 0.1596 0.0000

0.6952 1.0000 1.0000 0.7143 0.3333 1.0000 1.0000 0.5531 0.7745 0.1341 0.2500 0.3409 0.1270 0.2016 1.0000 0.2366 0.9091 1.0000 0.8875 1.0000 1.0000 1.0000 1.0000 0.9231 1.0000 1.0000 0.5641 1.0000 0.8535 0.8333 1.0000 0.5000 1.0000 1.0000 0.5692 0.7500 0.6573 0.7090 0.9130 0.3015 0.0817 0.2575 0.7333

0.5517 0.0000 0.0000 0.0000 0.8384 0.6619 0.1250 0.1667 0.2500 0.7000 0.6250 0.8000 0.7436 0.8906 0.1429 0.8644 0.0769 0.0000 0.0000 0.0588 0.2308 0.0000 0.3182 0.4762 0.3750 0.7416 0.2941 0.3030 0.0714 0.0769 0.0000 0.4000 0.0000 0.1111 0.2143 0.1000 0.0000 0.1250 0.0833 0.6000 0.9091 0.0000 0.6667

0.8161 0.0833 0.0000 0.0000 0.9798 0.9281 0.3750 0.1667 0.2500 1.0000 0.8750 0.8000 1.0000 0.9844 0.2143 0.9831 0.2308 0.1000 0.1000 0.1765 0.3846 0.1429 0.5000 0.7143 0.8125 0.9551 0.5294 0.4545 0.2143 0.3077 0.0000 0.6500 0.0000 0.2222 0.5000 0.2000 0.1111 0.1250 0.3333 0.9000 1.0000 0.7143 0.8333

0.9655 0.1667 0.0000 0.0000 1.0000 0.9928 0.8750 0.5000 0.6250 1.0000 1.0000 1.0000 1.0000 1.0000 0.2857 1.0000 0.3846 0.6000 0.6000 0.5882 0.6923 0.2857 0.8636 0.8095 0.8750 0.9775 0.8235 0.8788 0.5714 0.6154 0.0000 1.0000 0.3333 0.3333 0.9286 0.7000 0.7778 0.5000 0.6667 1.0000 1.0000 1.0000 0.9444

category therefore captures cases where round-robin fuzzing can reach the main or easier regions of the backbone, but struggles to extend exploration more uniformly into structurally harder areas. The remaining gaps in this regime are less suggestive of total driver inadequacy and more suggestive of uneven exploration pressure across subsystems, modes, or deeper execution stages. At the other extreme, some executables achieve relatively broad structural exploration and leave only limited residual pockets. Examples include lua, jq, snort2lua, bsdunzip, img_stat, file, and upx. These executables generally show high RC-Median values, low Frac(𝑟𝑐 = 0), and comparatively small Frac(𝑟𝑐 ≤ 0.5) values. In these programs, residual Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

31

under-exploration is no longer a backbone-wide phenomenon, but is instead concentrated in a limited set of regions. We group them into a category of broad exploration with localized residual pockets. This regime captures cases where it separates executables whose remaining gaps are narrow and concentrated from those whose residual structure is still broad or dominant. Such profiles indicate that round-robin fuzzing is already broadly effective at the structural level, and that the remaining hard regions are more likely tied to localized behaviors such as rare handlers, specialized modes, infrequent semantic branches, or narrow validation chains. Substantial residual heterogeneity also remains among executables from the same benchmark family. For example, snort and snort2lua, istat and img_stat, bsdtar and bsdunzip, and nccopy and ncdump exhibit clearly different residual profiles even though they belong to the same suite. This suggests that residual structural gaps are driven more by executable-level characteristics than by the benchmark family as a whole. It also indicates that under-exploration depends not only on the broader software family, but also on how each executable presents configuration modes, entry behavior, and internal structural pathways. 5.5.2 Case Studies by Residual-Gap Category. For readability, all case-study figures use the same notation and visual encoding. 𝑅𝑖 denotes a residual region identifier, 𝑅𝐶 its region coverage ratio after round-robin multi-driver fuzzing, 𝑆 the region size, 𝑈 representative uncovered function(s) in that region, and 𝐶 representative covered anchor or neighboring function(s) linking the region to already explored code (“–” indicates no clear covered anchor). In the graphs, red nodes denote uncovered regions, orange nodes denote weakly covered regions, and edges indicate structural connectivity among residual regions and the explored backbone. The quantitative patterns above show that residual under-exploration does not form a single homogeneous tail. Instead, different executables exhibit distinct residual-gap regimes, suggesting different underlying causes. We therefore examine representative case studies for each category to explain why such regions persist after round-robin multi-driver fuzzing. Case Study A: ffmpeg as a backbone-dominated residual-gap executable. ffmpeg is a representative example of the backbone-dominated residual-gap category. At the executable level, it retains severe residual under-exploration after round-robin multi-driver fuzzing: among 198 structural regions, the median region coverage is 0, 83.84% of regions remain completely uncovered, and 97.98% remain at or below a coverage ratio of 0.2. This profile indicates that the residual gap is not a small hard tail, but a backbone-wide phenomenon. Figure 7 helps explain why. The uncovered and weakly covered regions are associated with diverse media-processing routines, including amrwb_decode_frame, aac_decode_parse, opus_decode_packet, h264_parse, and atrac3_decode_frame. These are not repetitions of one narrow subsystem. Instead, they span multiple codec- and format-specific branches that sit behind distinct semantic preconditions, such as valid container structure, codec selection, stream metadata, packet layout, and stage-specific parser state. Thus, even though round-robin scheduling exposes multiple drivers, equal time sharing alone does not make these branches easy to reach. The limiting factor is not merely driver availability, but the difficulty of constructing inputs that satisfy the right semantic gates for each specialized path. The graph structure reinforces this interpretation. Several residual regions remain completely uncovered and appear at the periphery of the explored backbone, while others are connected to already exercised regions but still receive only negligible coverage. Most notably, R1 is large yet has RC=0.05, showing that the problem is not confined to tiny fringe components. Even structurally important regions remain weakly explored. This suggests that fuzzing can repeatedly enter the shared parsing and dispatch backbone, but tends to stay within easier or already-activated processing paths rather than crossing into harder codec-specific handlers. In other words, the bottleneck is a semantic access barrier: the campaign reaches the neighborhood of these regions, but rarely satisfies the precise input conditions needed to traverse them. Manuscript submitted to ACM

32

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

rc = 0

R14 R15 R17 R10 R5 R6 R7 R1 R3 R2 R4

RC=.00 RC=.00 RC=.00 RC=.01 RC=.02 RC=.03 RC=.03 RC=.05 RC=.08 RC=.13 RC=.13

0 < rc 0.2

S= 170 S= 104 S= 96 S= 293 S= 889 S= 754 S= 707 S=4195 S=2650 S=3161 S=2134

0.2 < rc 0.5

rc > 0.5

U=(amrwb|amrnb)_decode_frame U=ff_dca_core_parse U=(adts|latm)_decode_extradata U=aac_decode_frame U=avio_write,avio_wl32 U=opus_decode_packet U=avfilter_graph_send_command U=atrac3_decode_frame U=asf_read_packet U=asf_write_header U=dec_open

C= C= C= C=get_offset_and_codec C=avcodec_parameters_alloc C=fill_all_stream_timings C=h264_parse C=h264_decode_frame C=(avi|mpegts)_read_packet C=mov_probe C=ifile_open

Fig. 7. Case Study A: Backbone-dominated residual gaps in ffmpeg. Several residual regions remain fully uncovered (e.g., R14, R15, and R17), while even the large backbone region R1 is only weakly exercised (RC=0.05). These regions span diverse codec- and format-specific handlers, indicating that the residual gap is broad and structurally connected rather than an isolated fringe, and persists because many paths in the shared decoding backbone require strict format- and state-dependent semantic conditions.

Overall, this case study explains why ffmpeg falls into the backbone-dominated residual-gap category. Its remaining gaps are broad, structurally connected, and semantically heterogeneous. They persist because specialized decode and parse logic requires much stronger format-consistent inputs than round-robin scheduling and generic mutation alone can reliably provide. This also clarifies why adding multiple drivers is still insufficient here: the main challenge is not just having more entry points, but generating inputs that can unlock the correct deep media-specific execution modes. Case Study B: Partial exploration with a substantial residual tail. xmllint represents executables that achieve meaningful structural progress, yet still retain a broad low-coverage tail. Unlike the backbone-dominated failure pattern in Case Study A, residual under-exploration here is uneven rather than uniform: several regions are already meaningfully explored, including DTD/external-subset parsing (R4, RC=0.76), serialization/output handling (R9, RC=0.55), and notation/encoding-related logic (R10, RC=0.51). However, a substantial residual tail remains across other structurally connected regions. In particular, XPath evaluation is entirely uncovered (R8, RC=0), shell/debug-style inspection logic is entirely uncovered (R11, RC=0), and schema-facet validation is also entirely uncovered (R12, RC=0). Other advanced behaviors remain only weakly explored, including schema validation (R2, RC=0.08), Relax NG validation (R3, RC=0.23), and canonicalization (R6, RC=0.25). This pattern suggests that round-robin multi-driver fuzzing can reliably exercise the main document-processing backbone of xmllint, but does not extend coverage uniformly into specialized semantic modes. The remaining gaps persist not because the executable is broadly unreachable, but because deeper query, Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

33

validation, and transformation behaviors depend on more specific option, document, and internal state combinations than generic round-robin fuzzing can consistently satisfy.

rc = 0

R8 R11 R12 R2 R3 R6 R1 R5 R10 R9 R4

0 < rc 0.2

0.2 < rc 0.5

rc > 0.5

RC= .00 S= 116 U=xmlXPathRunEval C= RC= .00 S= 37 U=xmllintShellDir C= RC= .00 S= 25 U=xmlSchemaValidateFacet C= RC= .08 S= 351 U=xmlSchemaValidateDoc C=xmlParseXMLCatalogFile RC= .23 S= 288 U=xmlRelaxNGValidateDoc C=xmlTextReaderRead RC= .25 S= 140 U=xmlC14NExecute C=xmlParserPrintFileCont RC= .31 S= 520 U=doXPathQuery C=parseXml RC= .42 S= 191 U=htmlParseChunk C=xmlParseDocument RC= .51 S= 57 U=xmlSAX2NotationDecl C=xmlParseDocTypeDecl RC= .55 S= 97 U=htmlSaveFileFormat C=xmlSaveToFd RC= .76 S= 213 U=xmlCtxtParseDtd C=xmlParseXMLDecl

Fig. 8. Case Study B: Partial exploration with a substantial residual tail in xmllint. xmllint shows a mixed residual profile: several regions are already meaningfully explored (e.g., R4, R9, and R10), but a substantial tail of structurally connected regions remains weakly explored or uncovered. The hardest residual gaps concentrate in semantically richer behaviors, including XPath evaluation (R8), shell/debug inspection (R11), schema-facet validation (R12), schema validation (R2), Relax NG validation (R3), and canonicalization (R6).

Case Study C: Broad exploration with localized residual pockets. lua represents the regime in which round-robin multi-driver fuzzing already achieves near-complete structural exploration, and the remaining residual regions are limited in number, well-connected, and only mildly underexplored. Unlike the previous two categories, the residual profile here is not dominated by large uncovered backbone regions or a broad low-coverage tail. Instead, all shown residual regions are already substantially exercised, with coverage ratios ranging from 0.77 to 0.99. The remaining pockets concentrate in specific semantic behaviors, including pattern-matching and capture logic (R10), locale-sensitive numeric parsing (R6), script loading, and REPL-side execution (R2), binary chunk loading (R8), table/hash maintenance (R7), protected-call and coroutine recovery (R4), garbage-collection traversal of userdata and weak references (R5), VM/runtime edge cases (R3), and parser/code-generation diagnostics (R1). This pattern suggests that the main interpreter and runtime backbone of lua is already broadly reachable under multi-driver fuzzing, and that the remaining gaps persist mainly because these behaviors are triggered only under narrower semantic conditions, such as specific script constructs, malformed or boundary-case inputs, unusual runtime states, or binary-chunk formats. In other words, the Manuscript submitted to ACM

34

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

rc = 0

R10 R6 R2 R8 R7 R4 R5 R3 R1

0 < rc 0.2

0.2 < rc 0.5

rc > 0.5

RC= .77 S= 13 U=matchbalance C=match RC= .84 S= 61 U=localeconv C=lua_stringtonu RC= .86 S= 169 U=dofile C=doREPL RC= .88 S= 42 U=loadNumber C=luaU_undump RC= .93 S= 46 U=reinsertOldSli C=luaH_resize RC= .94 S= 89 U=finishpcallk C=luaD_pcall RC= .96 S= 70 U=traverseudata C=lua_gc RC= .96 S= 140 U=floatforloop C=luaV_execute RC= .99 S= 178 U=errorlimit C=luaY_checklimi

Fig. 9. Case Study C: Broad exploration with localized residual pockets in lua. All shown residual regions are already highly explored (RC=0.77–0.99), indicating that round-robin multi-driver fuzzing covers most of the interpreter and runtime backbone. The remaining low-intensity pockets cluster in specialized semantic behaviors, including pattern matching, numeric parsing, script and binary-chunk loading, table/hash maintenance, protected-call recovery, garbage collection, VM edge cases, and parser errors.

residual under-exploration is localized not because major functionality remains inaccessible, but because the remaining underexplored behaviors lie in specialized semantic corners of an otherwise well-explored executable. Residual region coverage after round-robin multi-driver fuzzing remains highly heterogeneous across executables and falls into three recurring regimes: backbone-dominated gaps, partial exploration with a substantial residual tail, and broad exploration with only localized residual pockets. These regimes reflect different sources of persistent underexploration, including stronger semantic barriers in some executables, uneven exploration of specialized paths in others, and only localized corner cases in the most thoroughly explored cases. Similar variation appears even within the same benchmark family, suggesting that residual structural difficulty is largely executable-specific rather than benchmarkwide. Overall, while multi-driver fuzzing substantially improves structural reachability, round-robin scheduling alone is often insufficient for uniform exploration of an executable’s shared backbone.

6

Discussion

Our results show that multi-driver fuzzing is beneficial, but its effectiveness depends strongly on the structural relationships among drivers. RQ1 showed that multi-driver fuzzing generally improves structural exploration over the best single-driver baseline. RQ2 further showed that equal time allocation does not produce equal driver contribution: Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

35

some drivers contribute disproportionately more than others, while some add little beyond already explored regions. RQ3 and RQ4 explain this behavior structurally, showing that driver-induced subgraphs differ not only in size, but also in cohesion, fragmentation, modular organization, and pairwise overlap. RQ5 extends this picture to residual structural coverage after combining drivers: executables do not exhibit one uniform residual tail, but instead fall into three recurring regimes: backbone-dominated residual gaps, partial exploration with a substantial residual tail, and broad exploration with localized residual pockets. Taken together, these results indicate that the benefit of multi-driver fuzzing is governed less by the mere number of drivers than by the structural diversity and complementarity they introduce, and by how effectively fuzzing penetrates the remaining cold regions of the shared backbone. A first implication is that driver sets should not be treated as flat collections of interchangeable execution modes. Some executables, such as sqlite3 and upx, exhibit highly redundant driver behavior: drivers contribute uniformly, induce structurally similar subgraphs, and overlap heavily. In such cases, adding more drivers yields little additional benefit. By contrast, executables such as ffmpeg, objdump, python, and lua show heterogeneous driver effectiveness, substantial structural variation, and mixed overlap structure. Here, multiple drivers expose complementary regions of the program and can substantially improve exploration. At the same time, RQ5 shows that such gains are not always sufficient to eliminate structural cold spots: depending on the executable, the remaining gaps may still involve most of the shared backbone, a broad low-coverage tail, or only a few localized pockets. This suggests that the value of a driver depends on its marginal structural contribution rather than its presence alone, and that multi-driver gains should be evaluated not only by total coverage improvement but also by how much residual cold structure remains. A second implication is that equal scheduling is not an adequate general policy for multi-driver fuzzing. Round-robin allocation is simple and fair at the driver level, but our results show that it does not ensure fairness at the structural level. When multiple drivers repeatedly traverse overlapping structural cores, time is spent reinforcing already hot regions, while cold regions remain under-explored. RQ5 makes this effect more explicit by showing that residual under-exploration is not distributed uniformly: in some executables, a large portion of the backbone remains cold even after combining multiple drivers, whereas in others the remaining difficulty is concentrated in a smaller set of stubborn regions. A scheduler that is unaware of structural redundancy may therefore waste fuzzing effort on drivers whose marginal contribution is low, or fail to distinguish between executables that require broad reallocation of effort and those that require more targeted triggering of residual pockets. More broadly, the results suggest that configuration-rich software should be viewed as a collection of partially overlapping execution subspaces. Different drivers expose different slices of the same program, and the relationships among these slices shape fuzzing outcomes. This perspective helps explain why multi-driver fuzzing sometimes yields dramatic gains and sometimes only marginal improvement. It also helps explain why residual under-exploration persists in different forms across executables: some programs remain blocked at a broad structural level, while others are limited mainly by a smaller set of semantically or structurally difficult regions. Future fuzzing tools should therefore reason about driver structure explicitly, rather than treating configuration modes as black-box entry points. Our findings also have implications beyond scheduling. For benchmark construction and evaluation, they suggest that reporting only aggregate coverage or bug counts may hide important structural differences among drivers. Two executables may achieve similar total coverage while differing substantially in redundancy, fragmentation, or residual cold-region structure. For tool builders, this means that structural analysis can provide actionable diagnostics: it can identify redundant drivers, reveal complementary driver families, and expose persistently cold regions that may require targeted generation, specialized inputs, or different scheduling priorities. Manuscript submitted to ACM

36

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li Several limitations should also be noted. Our structural analysis is based on driver-induced subgraphs projected onto

a static call graph, which provides a useful common reference but may not capture all dynamic relationships precisely. The region-level under-exploration analysis identifies persistent cold structure, but the quantitative summaries in RQ5 do not by themselves explain why a region remains hard to reach. That question requires follow-up inspection, which is why we complement the quantitative categorization with category-based case studies. In addition, the current study focuses on round-robin multi-driver fuzzing rather than more advanced adaptive scheduling strategies. These limitations do not affect the central findings, but they define natural directions for future work. Overall, the main lesson is that multi-driver fuzzing is fundamentally a structural exploration problem. Its success depends on how drivers partition, overlap, and complement one another in the program graph, and on how effectively fuzzing penetrates the residual cold structure that remains after combining them. Effective multi-driver fuzzing therefore requires more than simply adding drivers: it requires selecting, organizing, and scheduling them based on their structural relationships and their marginal contribution to under-explored regions.

6.1

Practical Implications

Our results suggest several practical implications for the design of driver-aware fuzzers. (1) Measure the marginal value of each driver. Different drivers contribute unevenly to exploration. A driver should not be treated as useful simply because it is present in the pool. Instead, a fuzzer should estimate how much new behavior or previously unreached program regions each driver contributes beyond what other drivers have already exposed. This implication follows directly from the observed heterogeneity in driver effectiveness across executables. (2) Account for overlap and redundancy among drivers. Our overlap analysis shows that many drivers repeatedly exercise highly shared program logic, especially common backbone behavior. This suggests that driver-aware fuzzers should explicitly reason about overlap, for example by grouping similar drivers, reducing effort on highly redundant ones, or selecting a smaller but more diverse driver set. In other words, adding more drivers is not always beneficial if they largely revisit the same behavior. (3) Prioritize drivers that extend exploration into weakly covered regions. Some drivers continue to push exploration into weakly covered parts of the program, while others mainly revisit already hot paths. This suggests that driver prioritization should depend not only on execution frequency or aggregate coverage gain, but also on whether a driver continues to open access to colder regions. Drivers that keep extending exploration into such regions are likely to be more valuable than drivers that mainly reinforce already saturated behavior. (4) Reallocate effort differently for different residual regimes. Our uncovered-region analysis reveals several recurring residual regimes, including backbone-dominated gaps, substantial residual tails, and localized residual pockets. These patterns likely reflect different forms of remaining difficulty and therefore should not be treated in the same way. Broad residual tails may call for broader reallocation toward under-explored modes, whereas localized pockets may benefit more from targeted triggering of narrow corner cases. This suggests that remaining gaps should be interpreted by regime when deciding how to redirect fuzzing effort. (5) Use richer feedback than aggregate coverage alone. Conventional feedback such as edge or function coverage summarizes how much of the program has been explored, but it does not reveal which regions are repeatedly revisited and which remain persistently cold. Our results therefore suggest that effective multi-driver fuzzing should incorporate Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

37

finer-grained feedback in addition to aggregate coverage metrics. Such feedback can better reveal whether fuzzing is broadening exploration or merely reinforcing an already hot shared core. (6) Improve driver–input combinations for persistent residual regions. Some regions remain under-explored even after combining multiple drivers. At the same time, the current study does not disentangle whether these gaps arise primarily from driver choice, input quality, or their interaction. A more defensible next step is therefore not to assume a driver-only or seed-only cause, but to improve the driver–input combinations associated with persistent residual regions. This may include better driver organization, more targeted invocation patterns, specialized input support, or other targeted exploration mechanisms for the remaining gaps. Overall, these implications show that effective multi-driver fuzzing requires more than simply running many drivers together. It requires reasoning about the distinct contribution of each driver, the redundancy among drivers, and the different forms of residual under-exploration that remain after combining them.

7

Threats to Validity

Internal validity. A threat to internal validity is whether the observed differences across drivers and executables are caused by the proposed analysis setting rather than by uncontrolled experimental factors. To reduce this risk, all comparisons use the same benchmark suite, the same driver specifications, and the same total fuzzing budget. For RQ1, multi-driver fuzzing is compared against the best single-driver baseline under equivalent budget. For RQ2–RQ5, all structural analyses are derived from dynamically observed execution results and are projected onto a shared contextinsensitive static call graph. Nevertheless, fuzzing is inherently stochastic, and these structural measurements depend on the executions reached during fuzzing. Randomness in seed selection, mutation outcomes, path discovery, and scheduling decisions may alter the covered nodes and edges, and therefore also affect the resulting driver-induced subgraphs and their derived statistics. As a result, changes in the initial seed corpus or in fuzzing randomness could lead to different observed structural measurements, including the residual region-coverage profiles used in RQ5. Our results should therefore be interpreted as characterizing structural behavior under the studied fuzzing configuration rather than as invariant properties of the programs themselves. Construct validity. A threat to construct validity is whether the selected metrics and constructed driver sets adequately capture the intended notions of effectiveness, heterogeneity, redundancy, and under-exploration. We use covered callgraph nodes and control-flow graph edges as proxies for structural exploration in RQ1, normalized per-driver call-graph coverage shares for driver effectiveness in RQ2, LCC ratio, #WCC, and modularity for structural organization in RQ3, pairwise IoU for overlap and redundancy in RQ4, and region-level coverage summaries for under-exploration in RQ5. In particular, RQ5 uses per-region coverage ratios together with summary statistics such as RC-Min, RC-Median, RC-Max, and threshold-based fractions of weakly covered regions, e.g., Frac(𝑟𝑐 = 0), Frac(𝑟𝑐 ≤ 0.2), and Frac(𝑟𝑐 ≤ 0.5), to characterize the severity and shape of residual structural gaps. These metrics capture complementary structural aspects, but they are derived from dynamically observed execution results rather than exhaustive program behavior. Moreover, the analyses are projected onto a context-insensitive static call graph. Such a graph provides a common structural reference across drivers and executables, but it may over-approximate feasible caller–callee relationships and may not precisely distinguish context-specific call behavior. As a result, some measured structural properties, such as connectivity, modularity, overlap, and residual region structure, may differ from those obtained under a more precise context-sensitive graph model. In addition, the structural regions used in RQ5 are analysis units induced by community detection on the shared call-graph backbone. Although this provides a systematic way to localize residual Manuscript submitted to ACM

38

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

gaps, different graph partitioning choices could produce somewhat different region boundaries and therefore somewhat different residual-coverage summaries or category assignments. The category construction in RQ5 should therefore be understood as a useful structural abstraction for organizing persistent under-exploration, rather than as a unique decomposition of the program. In addition, the analyzed drivers are constructed from main configuration options only. They do not exhaustively represent finer-grained parameter settings or other execution-shaping factors such as environment variables, configuration files, or runtime settings. The conclusions should therefore be understood as characterizing the studied driver abstraction and the observed structural exploration under a context-insensitive graph model, rather than the full semantic configuration space or exact dynamic calling structure of each program. External validity. A threat to external validity is whether the findings generalize beyond the evaluated benchmarks, constructed drivers, and fuzzing configuration. Our study covers a diverse set of widely used configuration-rich programs from domains including media processing, toolchains, language runtimes, storage systems, and document processing. This diversity improves generalizability, and several patterns recur across domains. However, the results may not directly transfer to software with very different architectures, to programs with limited configuration diversity, or to ecosystems where driver behavior is not well represented by command-line modes. In addition, the driver sets used in this study are constructed from main configuration options rather than from an exhaustive enumeration of all possible execution modes. We do not systematically vary option parameters within each driver, nor do we model other factors that may influence execution behavior, such as environment variables, configuration files, runtime settings, or external system state. Driver generation therefore remains only a partial approximation of the full configuration space, and driver generation itself remains an open research problem. Different driver-construction strategies may expose different structural regions, overlap patterns, effectiveness distributions, and residual region-coverage regimes. Similarly, the findings are based on the studied fuzzing setting and may differ under alternative seed corpora, input models, region-construction choices, or adaptive scheduling strategies. Thus, while the observed structural patterns appear broad, they should not be interpreted as universal across all programs, configuration mechanisms, driver-generation methods, or fuzzing scenarios. Conclusion validity. A threat to conclusion validity is whether the empirical evidence is sufficient to support the claimed relationships among driver diversity, structural overlap, and fuzzing outcomes. To mitigate this risk, we analyze the problem from multiple complementary perspectives: overall effectiveness (RQ1), contribution imbalance (RQ2), graph organization (RQ3), overlap and redundancy (RQ4), and structural under-exploration (RQ5). The consistency of these results strengthens the overall conclusions. Even so, some interpretations remain inferential. For example, we argue that overlap can reinforce already-hot regions, that structural complementarity can improve multi-driver gains, and that different residual-gap regimes in RQ5 reflect different kinds of remaining exploration difficulty. These interpretations are supported by converging structural evidence and category-based case studies, but they are not established through controlled causal manipulation. Therefore, the paper supports strong empirical associations and design implications, but causal claims about the exact mechanisms of driver interaction or residual under-exploration should be interpreted with appropriate caution. 8

Conclusion

This paper studied how multi-driver fuzzing explores software structure in real-world configuration-rich programs. We introduced an execution-driven structural abstraction that represents each program with a shared function-level call graph and derives driver-induced subgraphs from driver-specific dynamic executions. Using this abstraction, we conducted a large-scale empirical study over OSS-Fuzz-derived benchmarks to analyze structural diversity, overlap, Manuscript submitted to ACM

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

39

imbalance, and under-exploration across execution modes. Our results show that multi-driver fuzzing generally improves coverage over the best single-driver baseline, but also exhibits strong imbalance across drivers and leaves substantial structural regions persistently under-explored. These findings indicate that multi-driver fuzzing is not merely a matter of running more drivers, but of understanding how different execution modes partition and complement the program graph. Overall, this work provides an empirical foundation for more structure-aware fuzzing. Future work can build on this perspective to design better driver selection, scheduling, and feedback strategies for multi-mode software. References [1] Sebastian Baltes and Paul Ralph. 2022. Sampling in software engineering research: A critical review and guidelines. Empirical Software Engineering 27, 4 (2022), 94. [2] Vincent D Blondel, Jean-Loup Guillaume, Renaud Lambiotte, and Etienne Lefebvre. 2008. Fast unfolding of communities in large networks. Journal of statistical mechanics: theory and experiment 2008, 10 (2008), P10008. [3] Cisco Systems. 2024. Snort 3: an intrusion detection and prevention system. https://www.snort.org. [4] Cppcheck. 2024. Cppcheck: a static analysis tool for C and C++. https://cppcheck.sourceforge.io. [5] Nicolas Dugué and Anthony Perez. 2015. Directed Louvain: maximizing modularity in directed networks. Ph. D. Dissertation. Université d’Orléans. [6] Nicolas Dugué and Anthony Perez. 2022. Direction matters in complex networks: A theoretical and applied study for greedy modularity optimization. Physica A: Statistical Mechanics and its Applications 603 (2022), 127798. [7] FFmpeg. 2025. FFmpeg: a multimedia framework. https://ffmpeg.org. [8] file. 2024. file: a file type identification utility. https://www.darwinsys.com/file. [9] Andrew Forward and Timothy C Lethbridge. 2008. A taxonomy of software types to facilitate search and evidence-based software engineering. In Proceedings of the 2008 conference of the center for advanced studies on collaborative research: meeting of minds. 179–191. [10] Angelo Gargantini, Justyna Petke, Marco Radavelli, and Paolo Vavassori. 2016. Validation of constraints among configuration parameters using search-based combinatorial interaction testing. In International Symposium on Search Based Software Engineering. Springer, 49–63. [11] Git. 2024. Git: a distributed version control system. https://git-scm.com. [12] GNOME. 2024. an XML toolkit implemented in C. https://github.com/GNOME/libxml2. [13] GNU. 2024. GNU Binutils: binary utilities for object files. https://www.gnu.org/software/binutils. [14] google. 2022. Continuous Fuzzing Framework for Open Source Software. https://github.com/google/oss-fuzz. [15] Susan L. Graham, Peter B. Kessler, and Marshall K. McKusick. 1982. gprof: A Call Graph Execution Profiler. In Proceedings of the SIGPLAN Symposium on Compiler Construction. ACM, 120–126. [16] Mary W Hall and Ken Kennedy. 1992. Efficient call graph analysis. ACM Letters on Programming Languages and Systems (LOPLAS) 1, 3 (1992), 227–242. [17] Ahmad Hazimeh, Adrian Herrera, and Mathias Payer. 2020. Magma: A Ground-Truth Fuzzing Benchmark. In Proceedings of the ACM Conference on Computer and Communications Security (CCS). [18] Julien M Hendrickx and V Blondel. 2008. Graphs and networks for the analysis of autonomous agent systems. Ph. D. Dissertation. Catholic University of Louvain, Louvain-la-Neuve, Belgium. [19] jqlang. 2025. jq: a lightweight and flexible command-line JSON processor . https://github.com/jqlang/jq. [20] Sergej Klees, Andrew Ruef, Ben Cooper, Shiyi Wei, and Michael Hicks. 2018. Evaluating Fuzz Testing. In Proceedings of the ACM Conference on Computer and Communications Security (CCS). [21] Chris Lattner and Vikram Adve. 2004. LLVM: A compilation framework for lifelong program analysis & transformation. In International Symposium on Code Generation and Optimization, 2004. CGO 2004. IEEE, 75–86. [22] Ahcheong Lee, Youngseok Choi, Shin Hong, Yunho Kim, Kyutae Cho, and Moonzoo Kim. 2025. ZigZagFuzz: Interleaved Fuzzing of Program Options and Files. ACM Transactions on Software Engineering and Methodology 34, 2 (2025), 1–31. [23] Elizabeth A Leicht and Mark EJ Newman. 2008. Community structure in directed networks. Physical review letters 100, 11 (2008), 118703. [24] Jun Li, Bodong Zhao, and Chao Zhang. 2018. Fuzzing: a survey. Cybersecurity 1, 1 (2018), 6. [25] Wen Li, Haipeng Cai, Yulei Sui, and David Manz. 2020. PCA: memory leak detection using partial call-path analysis. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 1621–1625. [26] Wen Li, Jinyang Ruan, Guangbei Yi, Long Cheng, Xiapu Luo, and Haipeng Cai. 2023. PolyFuzz: Holistic Greybox Fuzzing of Multi-Language Systems. In 32nd USENIX Security Symposium (USENIX Security 23). 1379–1396. [27] Libarchive. 2024. Libarchive: a multi-format archive and compression library. https://www.libarchive.org. [28] Libdwarf. 2024. Libdwarf: DWARF debugging information access library. https://github.com/davea42/libdwarf-code. [29] LibTIFF. 2024. LibTIFF: a library for reading and writing TIFF images. https://gitlab.com/libtiff/libtiff. [30] Han-Lin Lu, Zong-Yuan Wu, Chien-Hsing Wu, Guan-Zhong Wang, and Shih-Kun Huang. 2024. Fuzzing Command-line Interface by Edge Coverage Guided Combinatorial Testing and Input Clustering. In 2024 IEEE 24th International Conference on Software Quality, Reliability and Security (QRS). Manuscript submitted to ACM

40

Baihong Chen, Hua Ming, Weifeng Pan, Tian Xie, Haipeng Cai, and Wen Li

IEEE, 516–525. [31] Lua. 2024. Lua: a lightweight embeddable scripting language. https://www.lua.org. [32] Valentin J. M. Manès, HyungSeok Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, and Maverick Woo. 2019. The Art, Science, and Engineering of Fuzzing: A Survey. In Proceedings of the 2019 IEEE Symposium on Security and Privacy (S&P). 979–999. [33] Ruijie Meng, Gregory J. Duck, and Abhik Roychoudhury. 2024. Program Environment Fuzzing. In Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS). 720–734. [34] Jonathan Metzman, László Szekeres, Abhishek Arya, Martin Pelikan, Rahul Arya, and Kostya Serebryany. 2021. FuzzBench: An Open Fuzzer Benchmarking Platform and Toolkit. In 30th USENIX Security Symposium (USENIX Security 21). [35] Gail C Murphy, David Notkin, William G Griswold, and Erica S Lan. 1998. An empirical study of static call graph extractors. ACM Transactions on Software Engineering and Methodology (TOSEM) 7, 2 (1998), 158–191. [36] M.Zalewski. 2014. Technical "whitepaper" for afl-fuzz. https://lcamtuf.coredump.cx/afl/technical_details.txt. [37] Meiyappan Nagappan, Thomas Zimmermann, and Christian Bird. 2013. Diversity in software engineering research. In Proceedings of the 2013 9th joint meeting on foundations of software engineering. 466–476. [38] Mark EJ Newman. 2003. The structure and function of complex networks. SIAM review 45, 2 (2003), 167–256. [39] NLnet Labs. 2024. Unbound: a validating, recursive DNS resolver. https://nlnetlabs.nl/projects/unbound. [40] Node.js. 2024. HTTP Parser: a parser for HTTP request and response messages. https://github.com/nodejs/http-parser. [41] Python Software Foundation. 2024. CPython: the reference implementation of Python. https://www.python.org. [42] QuickJS. 2024. QuickJS: a small and embeddable JavaScript engine. https://bellard.org/quickjs. [43] Michael Schröder and Jürgen Cito. 2022. An empirical investigation of command-line customization. Empirical Software Engineering 27, 2 (2022), 30. [44] SQLite. 2025. SQLite: a C-language library of SQL database engine. https://sqlite.org/. [45] Yulei Sui, Peng Di, and Jingling Xue. 2016. Sparse flow-sensitive pointer analysis for multithreaded programs. In Proceedings of the 2016 International Symposium on Code Generation and Optimization. 160–170. [46] Yulei Sui and Jingling Xue. 2016. SVF: interprocedural static value-flow analysis in LLVM. In Proceedings of the 25th international conference on compiler construction. 265–266. [47] Robert Swiecki. 2016. Honggfuzz. Available online at: http://code.google.com/p/honggfuzz (2016). [48] The HDF Group. 2024. HDF5: a data model, library, and file format for data storage. https://www.hdfgroup.org/solutions/hdf5. [49] The Sleuth Kit. 2024. The Sleuth Kit: digital forensics tools. https://www.sleuthkit.org. [50] Unidata. 2024. NetCDF: a set of software libraries and formats for array data. https://www.unidata.ucar.edu/software/netcdf. [51] UPX. 2024. UPX: an executable compressor. https://upx.github.io. [52] Dawei Wang, Ying Li, Zhiyu Zhang, and Kai Chen. 2023. { CarpetFuzz } : Automatic program option constraint extraction from documentation for fuzzing. In 32nd USENIX Security Symposium (USENIX Security 23). 1919–1936. [53] wavpack. 2025. wavpack: a completely open audio compression format. https://www.wavpack.com. [54] XpdfReader. 2024. an open source project includes a PDF viewer along with a collection of command line tools which perform various functions on PDF files. https://www.xpdfreader.com/opensource.html. [55] XZ Utils. 2024. XZ Utils: LZMA-based compression tools. https://tukaani.org/xz. [56] Cemal Yilmaz. 2012. Test case-aware combinatorial interaction testing. IEEE Transactions on Software Engineering 39, 5 (2012), 684–706. [57] Tao Zhang, Yu Jiang, Runsheng Guo, Xiaoran Zheng, and Hui Lu. 2020. A survey of hybrid fuzzing based on symbolic execution. In Proceedings of the 2020 International Conference on Cyberspace Innovation of Advanced Technologies. 192–196. [58] Xiaogang Zhu, Sheng Wen, Seyit Camtepe, and Yang Xiang. 2022. Fuzzing: a survey for roadmap. ACM Computing Surveys (CSUR) 54, 11s (2022), 1–36.

Manuscript submitted to ACM

Related documents

• IcFuzz: Fuzzing Isaac Sim with Semantic Stage Guidance and Multi-level Mutation#432593
• TraceLib: System-Call Bitmap Feedback Mechanism for Language-Agnostic Web Fuzzing#1129399
• TraceLib: System-Call Bitmap Feedback Mechanism for Language-Agnostic Web Fuzzing#1108829
• AIJon: Automated Generation of Annotations for Fuzzing#1012641
• AIJon: Automated Generation of Annotations for Fuzzing#965342