1
MASFuzzer: Fuzz Driver Generation and Adaptive Scheduling via Multidimensional API Sequences
arXiv:2604.17977v1 [cs.SE] 20 Apr 2026
Xingyu Liu, Zengqin Huang, Xiang Gao, Hailong Sun
Abstract—Fuzz testing of software libraries relies on fuzz drivers to invoke library APIs. Traditionally, these drivers are written manually by developers—a process that is not only timeconsuming but also often inadequate for exercising complex program behaviors. While recent studies have explored the use of Large Language Models (LLMs) to automate fuzz-driver generation, the resulting drivers still frequently fall short in covering deep program branches. To address these challenges, we propose MASF UZZER, a novel fuzzing framework that integrates multidimensional API sequence construction with adaptive fuzzing scheduling strategies to comprehensively enhance library testing. At its core, MASF UZZER synthesizes contextually relevant API call sequences by referring to the API usage examples from the codebase, and employing mutation-propagation-grounded and semantic-aware API sequence mining. Such multidimensional API sequences serve as the foundation for LLMs to generate effective initial drivers. In addition, MASF UZZER incorporates a coverage-guided scheduler that prioritizes testing time for the most promising drivers, along with a driver-mutation strategy to evolve them, thereby systematically generating fuzz drivers to explore previously untested code regions. We evaluated MASF UZZER on 12 widely-used opensource libraries, and the results show that MASF UZZER achieves 8.54% more code coverage than state-of-the-art techniques. Moreover, MASF UZZER successfully uncovered 16 previously unknown vulnerabilities in the extensively tested libraries (14 confirmed by the developer and 9 assigned with CVE IDs). These results demonstrate that MASF UZZER provides a more efficient and practical solution for fuzzing software libraries.
process is both time-consuming and labor-intensive. Moreover, the effectiveness of the resulting fuzz drivers heavily relies on the programming expertise of developers [9], [10]. As a result, both academia and industry have devoted increasing efforts to automate fuzz-driver generation. Existing research on automated fuzz-driver generation follows two main paradigms: static analysis–based construction and LLM-based semantic synthesis. The first strand mines API usage sequences from concrete code examples (e.g., FUDGE [11]) or model static constraint relationships among APIs (e.g., GraphFuzz [12]) to construct fuzz drivers. Although showing promising results, such methods inherently lack deeper semantic reasoning and are constrained by the limited diversity of existing usage patterns. The second approaches automate fuzzdriver generation [13], relying on Large Language Models (LLMs), which have shown impressive capabilities in coding tasks. These methods range from directly prompting LLMs with API signatures (e.g., OSS-Fuzz-Gen [14] and PromptFuzz [15]) to more structured approaches that integrate external knowledge sources, such as API knowledge graphs (e.g., CKGFuzzer [16]) or retrieval-augmented generation from consumer code and documentation (e.g., PromeFuzz [17]). Despite these advances, existing approaches still face several fundamental limitations:
Index Terms—Fuzzing, Fuzz Driver Generation, Large Language Models, Software Security.
•
I. I NTRODUCTION Fuzz testing (fuzzing) is one of the most effective techniques for identifying software vulnerabilities [1]–[4]. It works by providing a large volume of inputs to a target program, triggering potential abnormal behaviors [5]. Fuzzing libraries is of particular significance, as it enables systematic exploration of API behaviors and uncovers vulnerabilities that are otherwise difficult to detect through application-level testing [6], [7]. Since fuzz testing typically relies on a single program entry point, fuzzing a library requires an auxiliary program that instantiates objects and invokes APIs in a valid sequence. Such programs are commonly called fuzz drivers [2]. Traditionally, fuzz drivers are manually written by experienced developers. For example, Google’s OSS-Fuzz project [8] involves many developers to write fuzz drivers in order to integrate a wide range of open-source libraries. Nevertheless, this Xingyu Liu, Xiang Gao, and Hailong Sun are with Beihang University, China (e-mail: [email protected]; xiang [email protected]; [email protected]). Zengqin Huang is with Jinan University, China (e-mail: [email protected]). Corresponding author: Xiang Gao(e-mail: xiang [email protected]).
Limited and Fragmented API Context: Existing approaches generate API sequences from a single source—static code patterns, syntactic constraints, or LLMinferred semantics. This results in drivers that are either syntactically correct but semantically shallow, or semantically rich but unreliable. The absence of a unified, multi-faceted API context model limits the system’s ability to generate drivers that are both syntactically diverse and semantically grounded. • Fixed and Uniform Execution Strategy: Current systems treat all generated drivers equally, allocating the same fuzzing time and resources to each. They lack a mechanism to dynamically prioritize drivers that demonstrate higher coverage potential or to reallocate energy away from stagnant ones, leading to inefficient resource utilization.
To overcome the above limitations, we present MASF UZZER, a novel framework for fuzz driver generation and scheduling. First, to address the problem of a limited and static API context, we introduce a multidimensional API sequence construction method. Instead of relying on a single information source, we systematically synthesize API invocation contexts from three complementary perspectives: (1) extracting sequential patterns from real code examples to ensure realism, (2) leveraging type signatures to guarantee syntactic validity, and (3) employing LLM-based semantic analysis to propose novel,
2
semantically plausible API combinations. This enriched, multidimensional context provides the foundation for generating drivers that are both robust and exploratory. Second, to tackle the inefficient, uniform resource allocation for fuzzing each driver, we design a coverage-guided time scheduler. Unlike static scheduling, our scheduler continuously monitors each driver’s runtime coverage feedback and dynamically prioritizes fuzzing energy. Drivers that demonstrate higher potential to uncover new code paths receive significantly more execution time, while stagnant drivers are deprioritized, ensuring optimal resource utilization throughout the campaign. Moreover, we enhance driver evolution with a sequence-aware mutation strategy, which utilizes our multidimensional sequences to intelligently alter API call orders, enabling more focused exploration of uncovered program states. We evaluated MASF UZZER on 12 widely-used open-source libraries. In terms of code coverage, compared with stateof-the-art tools, P ROME F UZZ [17], CKGF UZZER [16] and L IB E RATOR [18], MASF UZZER achieves coverage improvements in 11 of these libraries, with an average increase of 8.54%, 15.07% and 37.95%, respectively. We further conducted ablation studies to analyze the contributions of different components, including multidimensional API sequences, and the time scheduler and mutation strategy. The results demonstrate that each of these modules contributes to the overall effectiveness of MASF UZZER to varying degrees. Although these libraries have been extensively tested, MASF UZZER successfully discovered 16 previously unknown bugs in these libraries (14 confirmed by the developer and 9 assigned with CVE IDs). In summary, we make the following contributions in this work: • We propose a novel approach for constructing multidimensional API sequences. By extracting usage examples from the original codebase and performing mutation-propagationgrounded and semantic-aware API sequence mining, we generate API sequences along three complementary dimensions, providing rich contextual information to guide LLMs in generating high-quality fuzz drivers. • We design and implement MASF UZZER, a fuzzing framework that combines fuzz driver generation driven using multidimensional API sequences, a coverage-guided time scheduler and sequence-aware driver mutation, enabling more effective library testing. • We perform an extensive evaluation of MASF UZZER across 12 widely-used libraries. The results demonstrate that our approach significantly improves code coverage compared to state-of-the-art techniques and has uncovered 16 previously unknown vulnerabilities (14 confirmed by the developer and 9 assigned with CVE IDs). II. BACKGROUND AND M OTIVATION A. Library Fuzzing Fuzzing is a widely used software testing technique for automatically discovering vulnerabilities in programs [19], [20]. It works by continuously generating large numbers of
inputs and feeding them to the program under test (PUT) to expose crashes. Among various fuzzing paradigms, coverageguided grey-box fuzzing (CGF) has become the de facto standard [21], [22]. CGF uses lightweight instrumentation to collect code coverage feedback, which is then used to guide input generation and steer exploration towards deeper program behaviors [23]. While CGF is highly effective for standalone programs, fuzzing software libraries presents a unique challenge. Unlike programs with a clear entry point (e.g., a main function), libraries typically expose functionality only through their Application Programming Interface (API). As a result, fuzzing them requires a test harness, or fuzz driver, that specifies how to invoke the library functions. Manually writing such fuzz drivers is notoriously difficult and time-consuming. It demands a deep understanding of the library’s semantics, and then carefully handles the initialization and state management, and the construction of meaningful API call sequences. Any mistakes in fuzz drivers can easily limit the fuzzing effectiveness and even introduce spurious crashes. Several approaches have been proposed for automated fuzzdriver generation. Some approaches rely on user-provided specifications of the APIs under test [12], [24], while others learn API usage patterns from existing consumer code [6], [11]. More recent works, such as P ROME F UZZ [17], CKGF UZZER [16] and P ROMPT F UZZ [15], leverage advances in Large Language Models (LLMs) to aid fuzz-driver generation. LLMs such as GPT-4 [25] and CodeLlama [26] have shown remarkable capabilities in understanding and generating humanlike text and source code [27], [28]. In addition, they can learn complex syntactic and semantic patterns from large code corpora, enabling applications in code generation and testing [29]–[36]. As a result, LLMs have emerged as a promising alternative in this regard. [37], [38] B. Motivating Example Despite advances in LLM-based fuzz driver generation, constructing effective API sequences to explore deep program behaviors remains challenging. To motivate our approach, we present a buffer-overflow vulnerability in the libplist library, which was discovered by MASF UZZER but missed by the previous techniques, including P ROMPT F UZZ [15], CKGF UZZER [16], and P ROME F UZZ [17]. The corresponding fuzz driver generated by MASF UZZER is shown in Figure 1. To expose this vulnerability, the fuzz driver first parses XML input (i.e., data) and converts it into plist structure (lines 3– 4), copies it (lines 5–6), and converts the copy into an openstep representation (lines 7–10). The issue occurs during the copy at line 6: if the XML input contains \0 bytes, plist copy allocates memory and copies data only up to the null byte, since it relies on strdup for allocation. However, the internal length metadata of the plist node preserved during the copy still records the original XML length, rather than the truncated size. As a result, when plist_to_openstep is invoked at line 10, it steers its data access based on its internal metadata, thereby causing it to read beyond the allocated buffer and triggering the vulnerability.
3
int LLVMFuzzerTestOneInput(uint8_t *data, size_t ,→ size) { 2 plist_t xml_plist = nullptr; 3 if ( plist_from_xml ((const char*)data, ,→ (uint32_t)size, &xml_plist) == ,→ PLIST_ERR_SUCCESS && xml_plist) { 4 plist_type node_type = ,→ plist_get_node_type(xml_plist); 5 if (node_type != PLIST_NONE) { 6 plist_t copied_plist = ,→ plist_copy (xml_plist); 7 if (copied_plist) { 8 char* openstep = nullptr; 9 uint32_t openstep_len = 0; 10 if ( plist_to_openstep (copied_plist, ,→ &openstep, &openstep_len, 0) == ,→ PLIST_ERR_SUCCESS) { 11 if (openstep) free(openstep); 12 } 13 plist_free(copied_plist); 14 } 15 } 16 plist_free(xml_plist); 17 } 18 return 0; 19 } 1
Fig. 1. Simplified fuzz driver generated by MASF UZZER that exposes a previously unknown buffer overflow in libplist.
Based on this fuzz driver, the invoked API sequence exhibits two critical categories of dependencies. The first is the type dependency, where the return type of plist_copy directly matches the parameter type of plist_to_openstep, ensuring that data can correctly flow across APIs to form a valid data flow. Moreover, there is the semantic dependency, where plist_from_xml must be invoked before plist_copy so that the XML input is properly parsed into a plist that is the required argument for plist_copy. This semantic dependency is not only enforced by type constraints but also arises from the correct ordering of API usage. However, existing techniques fail to accurately infer and cover these dependencies in the fuzz drivers they generate. P ROMPT F UZZ only provides selected library API functions and then prompts the LLMs to generate fuzz drivers. Since there is no detailed guidance, LLMs struggle to capture all the type dependencies and enforce correct API ordering. CKGF UZZER attempts to mitigate this issue by constructing function-level call graphs, while P ROME F UZZ computes different relevance scores among APIs and selects highly correlated APIs to compose fuzz drivers. Although these strategies can partially mitigate the problem, they still miss many sequential dependencies. For the example in Figure 1, reaching the bug requires the sequence from plist_from_xml to plist_copy, but there is no direct function call relationship between them. Consequently, CKGF UZZER, which relies on call graphs, fails to capture this connection. Similarly, P ROME F UZZ overlooks this dependency; its relevance-based selection filters out the generic plist_copy due to its weak association with the core conversion task. Motivated by this insight, we propose MASF UZZER, which incorporates multidimensional API sequences during fuzz-driver generation. In the example shown in Figure 1,
MASF UZZER is able to capture type dependency between plist_copy and plist_to_openstep, forming one dimension of the sequence, as well as the semantic dependency between plist_from_xml and plist_copy, forming another dimension. By providing the above two dimensions of correlated API sequences in the LLM’s context, MASF UZZER enhances semantic richness while ensuring syntactic correctness. This enables it to generate effective fuzz drivers and, by allocating more execution time to this driver through the dynamic scheduling strategy, successfully produce XML inputs containing null bytes, thereby covering previously unreachable code branches and ultimately discovering previously unknown bugs. III. M ETHODOLOGY A. Overview MASF UZZER is a general-purpose fuzzing framework designed to automatically generate high-quality fuzz drivers, and to perform dynamic scheduling and mutation during execution. Its overall workflow is illustrated in Figure 2, which consists of six stages. At stage ①, MASF UZZER first constructs API sequences—temporal chains of API calls—to guide fuzz driver generation. These sequences are produced in three complementary ways: (1) extracting real-world usage patterns for reliability, (2) composing type-compatible APIs, and (3) leveraging LLMs for semantic analysis to explore new logical flows. This multidimensional approach captures both real-world usage patterns and potential novel scenarios. These generated API sequences with type information and semantic context are used to construct LLM prompts and generate candidate fuzz drivers. To ensure correctness, at stage ②, a dedicated verification agent automatically repairs compilation errors by iteratively analyzing failed builds and applying corrective patches. For each generated fuzz driver, MASF UZZER constructs an initial seed corpus at stage ③ by extracting information from documentation. After that, with the generated fuzz drivers and the selected seeds, MASF UZZER implements a runtime driver scheduling mechanism to dynamically assign execution time to each driver at stage ④. The scheduler evaluates fuzz drivers based on their sequence-level similarity and API-level coverage. The scheduler prioritizes drivers with lower coverage while skipping those that have already reached a predefined threshold to avoid redundant testing. After this stage, the fuzz drivers are executed by the fuzzer. If a driver fails to uncover new branches (stage ⑤), MASF UZZER evaluates the fuzzing potential energy and coverage of their associated APIs, and selects a mutation strategy that emulates the seed mutation process in fuzzing to generate a new fuzz driver. In addition, MASF UZZER introduces a crash analysis agent that leverages LLM to systematically analyze fuzz drivers and crash information, distinguishing between API misuse and real library bugs (stage ⑥). In the following, we mainly introduce how MASF UZZER generates API sequences (stage ①), schedules different fuzz drivers (stage ④), and mutates them (stage ⑤) in more detail. For the other stages ② ③ and ⑥, MASF UZZER adopts similar strategies to those used in existing works [15]–[17].
4
② Fuzz Driver Generation and Repair
① Multidimensional API Sequences Construction
Parse C/C++ Library
Metainfo
Extract
API Sequences from Usage Examples
Type Match
API Sequences via Mutation-Propagation-Grounded Mining
Semantic Analyse
Construct
API Sequences via Semantic-Aware Mining
Fuzz Drivers
Prompt
Compile Check
Multidimensional API Sequences
Update
Select Strategy
Repair Agent Fuzzer
New Drivers
Mutation Agent
Ineffective Drivers
⑤ Fuzz Driver Mutation
Crash Analyse Agent
Seed Corpus
Coverage Data
Initialize
Calculate
Analyse Bugs
High-quality Fuzz Drivers
Time Scheduler
Crashes
⑥ Crash Analysis
④ Fuzz Driver Scheduling
Seeds
Seed Generation Agent
③ Seed Selection
Fig. 2. Overall workflow of MASF UZZER.
B. Multidimensional API Sequences
int main() { lxw_workbook *wb = workbook_new(FILE); 3 lxw_worksheet *ws = ,→ workbook_add_worksheet(wb, NULL); 4 lxw_format *fmt = ,→ workbook_add_format(wb); 5 format_set_bold(fmt); 6 worksheet_write_number(ws, 0, 1, 0, ,→ NULL); 7 ... 8 worksheet_write_array_formula(ws, ,→ RANGE("A1:A3"), ,→ "{=SUM(B1:C1*B2:C2)}", fmt); 9 return workbook_close(workbook); 10 } 1 2
Multidimensional API sequences model valid API usage orders, providing the domain-specific insights needed for fuzz driver generation. The process begins with a syntactic analysis of the target library to extract function-level metainfo— including signatures, bodies, file names, line numbers, and documentation comments. This metadata forms the basis for constructing valid API sequences from three distinct and complementary perspectives. 1) API Sequences from Usage Examples: Within the library source code itself, sequences of public APIs are frequently invoked. These invocations—commonly found in example programs, unit tests, and fuzzing tests—implicitly reveal the correct usage patterns and constraints of public APIs. Figure 3 shows a typical usage scenario implemented by developers in the libxlsxwriter library, which is a widely used library for programmatically generating Excel (XLSX) files. This example illustrates a representative API usage sequence, covering object creation, format configuration, data and formula writing, and finally closing the workbook to release resources and generate the file. Formally, we define the API sequences from usage examples as follows. Given the code repository of a library, let the set of public APIs be A = {a1 , a2 , . . . , am }. MASF UZZER first performs the abstract-syntax-tree (AST) and control-flowgraph (CFG) parsing to extract sequences of APIs invoked in the source code of the library itself. Within in a sequence of invoked APIs S, if there exist at least two invoked APIs ai , aj ∈ S such that ai , aj ∈ A, then we consider that there exists a useful API sequence within S, represented as an ordered set Seque , where Seque is a subsequence of S
Fig. 3. API sequence extracted from usage example.
and {∀ai ∈ Seque | ai ∈ A}. The order of elements in Seque reflects the sequential invocation order of the APIs from real developers. These sequences are directly extracted from authentic source code and are explicitly constructed and validated by developers, thereby embodying the most semantically rich and practically reliable API usage patterns. However, since these sequences are derived from existing usage patterns, they are primarily valid sequences, but exhibit limited capability in discovering new coverage. Unlike FUDGE [11] and FuzzGen [6], which directly splice extracted sequences to generate code, MASF UZZER treats these API sequences merely as an exemplary skeletal reference. By deeply fusing them with multidimensional API sequences, MASF UZZER leverages LLMs to effectively break the limitations of static real-world use cases.
5
2) API Sequences via Mutation-Propagation-Grounded Mining: A well-constructed fuzz driver must possess a key property that we call Mutation Propagation Completeness (MPC). MPC ensures that: (1) The fuzzer input can thoroughly exercise the entire API sequence; (2) each API call is sensitive to input variations, i.e., distinct inputs alter the API call’s output or internal state; and (3) these changes propagate through the sequence, enabling that a single mutation can influence subsequent behaviors and reach deeper program states. To satisfy the MPC property, we propose a API sequences via mutation-propagation-grounded mining paradigm. Specifically, when the return type of an API A is type-compatible with the parameter type of another API B, it indicates that the output of A can be propagated to B, thereby forming an interAPI data transfer channel. Formally, we provide the definition and construction process of API sequences via mutationpropagation-grounded mining: (1) Type Compatibility Definition. For two API ai and aj , compatible(ai ,aj ) is true if and only if: ∃ pj ∈ Params(aj ) such that
Type(Return(ai )) = Type(pj )
Here, Type(pj ) denotes the type of parameter pj , indicating that the output of ai can flow into the input of aj . (2) Compatibility Graph Construction. Given an API set A = {a1 , a2 , . . . , an }, their compatibility graph a directed graph G = (V, E): ( V =A G= E = {(ai , aj ) | compatible(ai , aj ) for ai , aj ∈ A} For input parameters and return values that are difficult to parse due to complex macro definitions, we leverage LLMs to perform more complete and reliable supplementary analysis. Note that, we primarily focus on the type-compatible relationships between structs and classes. For primitive data types (e.g., char and int), we assume that these values can be obtained directly or indirectly through input data mutation during fuzzing. Moreover, including primitive types in typecompatibility analysis could introduce excessive false-positive propagation edges, thereby diluting the precision of our sequence mining. (3) Sequence Generation. We traverse the compatibility graph G using a depth-first search (DFS). The traversal begins with nodes with zero in-degree and constrains a maximum sequence length of L. The resulting set of API sequences is defined as: m [ Seqmp = DFS(vk , G, L), ∀ vk ∈ {v | indegree(v) = 0} k=1
DFS(vk , G, L) denotes a depth-first search starting from node vk , which terminates either when a leaf node is reached or when the path length reaches the threshold L. To effectively mitigate potential path explosion, we enforce strict cycle avoidance during traversal to prune redundant loops. Subsequently, we randomly sample the extracted valid paths to form the final set Seqmp , which represents a diverse pool of viable API sequences that satisfy the type-compatible propagation constraint.
3) API Sequences via Semantic-Aware Mining: Overall, API sequences constructed via mutation-propagation analysis enable the synthesis of API sequences that are not explicitly present in the original codebase but may still be functionally valid. However, this approach relies heavily on the accurate parsing of parameter and return types. Consequently, APIs that lack input arguments, return void, or whose input and output types do not satisfy type-compatibility criteria cannot be incorporated into API sequences. Moreover, sequences formed solely by type analysis may not always be semantically meaningful. A sequence might combine APIs in a syntactically valid but logically incoherent manner—such as creating an object and immediately deleting it, without any meaningful operations in between. To solve this problem, we further propose API sequence generation from semantic analysis. To systematically derive semantically coherent API sequences, the construction workflow is structured into three stages: semantic extraction, semantic relationship identification, and sequence synthesis. First, in the semantic extraction stage, LLM is prompted with API metadata (e.g., signatures and documentation snippets) and code to obtain structured semantic descriptions for each API. These descriptions summarize the functional role and usage context of the API, serving as semantic anchors for subsequent analysis. Second, during relationship identification, MASF UZZER feeds both the original API metadata and the extracted semantic descriptions into a relationship-prediction prompt. This prompt guides the LLM to infer semantically meaningful predecessor-successor relationships between APIs—capturing dependencies, logical ordering, and contextual relevance that are often missed by purely syntactic or type-based methods. Finally, MASF UZZER utilizes the identified semantic relationships to construct API sequences Seqsem . ares_library_init(...)→ ares_init(...)→ ares_gethostbyname(...)→ ,→ ares_destroy(...)→ ares_library_cleanup(...) Fig. 4. API sequence from semantic analysis.
Figure 4 demonstrates an API sequence via semanticaware mining. All APIs in this sequence originate from the c-ares library, which is an asynchronous DNS resolver. In this example, the correct execution of the function ares_gethostbyname depends on the prior invocation of the following two functions: ares_library_init, which correctly initializes the global library state, and ares_init, which properly initializes the channel variable. Notably, this dependency relationship is not conveyed through explicit parameters or return values, making it unrecognizable by conventional type analysis. Instead, their effects manifest implicitly via global state changes and variable initialization. As a result, static analysis fails to establish the calling relationship among these APIs. In contrast, semantic analysis leverages an understanding of APIs’ functional descriptions and semantic relationships to accurately identify that ares_gethostbyname semantically depends on prior
6
global initialization. This enables constructing the correct invocation order and dependency path. 4) Integrated API Sequences for Fuzz Driver Generation: Overall, the three sequence types serve complementary roles in fuzz driver generation. Usage-example sequences Seque capture common and reliable invocation patterns observed in real-world code, providing a stable backbone for driver construction. Mutation-propagation sequences Seqmp extend beyond typical usage by modeling inter-API data-flow compatibilities, exposing previously unexplored yet syntactically feasible call chains with high coverage potential. Semantic sequences Seqsem incorporate contextual dependencies and logical constraints that static analysis cannot capture, thus mitigating API isolation and enriching the sequence space with semantic-aware variations. To synthesize high-quality fuzz drivers, we integrate these multidimensional sequences into a structured prompting strategy. For each target API, we select one representative, previously unused sequence of maximal length from each of the three categories. Each sequence type is assigned a distinct role in the prompt: Seque serves as the structural backbone, preserving realistic and stable invocation patterns; Seqmp acts as a coverage-extending variant, introducing type-compatible call reorderings that break out of common usage boundaries; Seqsem functions as a semantic complement, injecting context-sensitive dependencies that guide the LLM toward semantically consistent API compositions. For a certain API, if the API sequence of any category is missing, MASF UZZER just relies on the sequences from available categories. A prompt instructs the LLM to combine these three perspectives—preserving the natural ordering from Seque , incorporating mutation-aware extensions from Seqmp , and respecting semantic constraints from Seqsem —to generate a unified fuzz driver that is both syntactically correct and semantically directed toward deeper state exploration. C. Coverage-Guided Time Scheduler Most fuzz driver frameworks [15]–[17], [39] assume that all generated drivers are equally effective in testing and, therefore, allocate an identical execution time to each driver. However, in practice, different fuzz drivers exhibit substantially different testing potentials. Ideally, drivers with higher potential should be assigned more execution time to explore deeper program states and exercise hard-to-reach branches. Furthermore, code coverage generally follows the law of diminishing marginal returns [40]. As fuzzing progresses, APIs targeted by later drivers are often already extensively covered during earlier testing phases. Under such circumstances, continuing to allocate time uniformly across all drivers exacerbates resource inefficiency and leads to a fundamental dilemma: on the one hand, high-potential drivers cannot obtain additional execution time to fully show their exploration capability; on the other hand, drivers scheduled later may be constrained by the remaining time budget, preventing them from triggering complex and deep execution paths. To address these challenges, we propose a coverage-guided time scheduler that dynamically adjusts the execution time of
Algorithm 1: Coverage-Guided Time Scheduling Cov ← initCov(); Sexec ← ∅ ; 3 foreach i ∈ range(0, |D|) do 4 uniqueAPIsP← removeDuplicates(D[i]); 1 2
api∈uniqueAPIs P
5
avgCov ←
6
if avgCov > θ then continue;
7 8 9 10 11
covered(Cov [api])
api∈uniqueAPIs total(Cov [api])
;
else αt ← Bound(B i/|D|−1 , αmin , αmax ); t ← T /|D| × αt ; ωnovelty ← min Levw (Seq(D[i]), S)/|Seq(D[i])|; S∈Sexec
12
tassign ← (t/ max(avgCov , β)) × ωnovelty ;
13
tactual , newCov ← ExecuteFuzzDriver(D[i], tassign ); if newCov = ∅ then D′ [i] ← Mutate(D[i]) // Section III-D tactual , newCov ← ExecuteFuzzDriver(D′ [i], tassign );
14 15 16
17 18 19
T ← T − tactual ; Cov ← Cov ∪ newCov ; Sexec ← Sexec ∪ {Seq(D[i])};
each fuzz driver. Before a driver is executed, the scheduler evaluates its potential testing value based on current multidimensional sequence-level and API-level coverage feedback, and allocates an appropriate runtime budget accordingly. This design ensures that each driver is assigned an execution time proportional to its remaining fuzzing potential. The details of the scheduling algorithm are illustrated in Algorithm 1. The coverage-guided time scheduling algorithm processes each fuzz driver through a systematic procedure. For the i-th driver D[i], the algorithm first extracts unique APIs through deduplication. It then calculates the current average coverage avgCov , where Cov provides historical coverage data for each API. Drivers exceeding the coverage threshold θ are immediately skipped to optimize resource utilization. For drivers requiring execution, the algorithm computes a time coefficient αt using an exponential function based on the proportion of remaining drivers (i/|D| − 1), bounded between [αmin , αmax ]. This approach, inspired by the simulated annealing algorithm used by AFLGo [3], ensures balanced time allocation throughout the fuzzing process. The scheduler introduces a novelty factor ωnovelty , to effectively leverage sequence information for further capturing the testing potential of fuzz drivers. This factor is computed based on the minimum weighted edit distance between the current sequence and the set of historical sequences, where dimensionspecific weights are applied and normalized across different sequence dimensions. Fuzz drivers whose execution paths are highly similar to previously explored ones are regarded as redundant and thus allocated less execution time. The base time allocated t is derived from the proportional
7
time share adjusted by αt . The final assigned time tassign is then computed by inversely scaling with the coverage. Higher coverage results in proportionally less execution time, with a lower bound determined by β to prevent excessive time allocated to low-coverage drivers. After time assignment, the driver executes for the specified duration, returning actual execution time tactual and new coverage data newCov . The driver that fails to discover new branches then undergoes mutation using predefined strategies and is re-executed, followed by updates to the remaining total time T and the aggregated coverage information Cov . This strategy is designed to achieve an optimal balance between thorough testing and time efficiency by prioritizing drivers with lower coverage while maintaining a fair resource distribution across all drivers. D. Sequence-Aware Mutation Strategy To enhance fuzzing coverage, MASF UZZER automates the generation of diverse fuzz drivers, aiming to explore more execution paths. However, not all of the generated drivers are effective—some fail to reach new execution paths or trigger potential crashes during fuzzing. To address these ineffective drivers, we propose a novel fuzz driver iterative refinement mechanism that integrates coverage-guided mutation with multidimensional API sequence features, enabling the iterative generation of more effective and diverse fuzz drivers. The mutation strategy consists of two stages: energy allocation scheme and mutation strategy selection. Energy Allocation Scheme. Previous fuzzing frameworks [15], [16], [41] have introduced the concept of energy to represent the execution potential of an API, where APIs with higher energy are prioritized during fuzz driver construction. However, traditional energy calculations often rely solely on coverage, while overlooking how an API is used across potential API sequences. To address this limitation, we introduce a new metric called potential, which characterizes the usage potential of an API based on the number of distinct API sequences in which it appears. Formally, the novel energy computation formula is defined as follows: energy(api) = (1 − cov(api)) × (1 − freq(api)) × potential(api) Here, cov(api) denotes the branch coverage ratio of the API, reflecting the proportion of its branches that have already been exercised—higher values indicate better-tested APIs, and freq(api) represents the proportion of executed fuzz drivers that invoke this API—higher values imply more frequent usage. Moreover, potential(api) captures the number of multidimensional API sequences in which the API appears, reflecting its semantic diversity and usage richness. Together, these three components integrate both static and dynamic aspects of API behavior to quantify its energy for guiding fuzz driver refinement. Mutation Strategy Selection. Traditional mutation strategies in fuzzing primarily target the input data fed into the program under fuzz. In contrast, P ROMPT F UZZ extends the mutation process to the level of API within the fuzz driver itself. Building upon this insight, we propose an enhanced
sequence-level Mutation Strategy Selection mechanism that incorporates multidimensional API sequences (Seque ∪ Seqmp ∪ Seqsem ) to guide the generation of more effective fuzz drivers. Specifically, during each mutation iteration, our approach first identifies the API with the highest energy and retrieves an unused API sequence associated with it, and then randomly selects one of three mutation strategies—Insert, Replace, or Combine. • The Insert strategy inserts the selected API sequence into a semantically compatible position within the current API sequence; • The Replace strategy replaces a randomly selected subsequence in the current API sequence with the selected API sequence, preserving type and semantic consistency; • The Combine strategy merges the selected API sequence with the API sequence of the current fuzz driver. By applying these strategies, our method integrates highpotential API sequences associated with higher-potential APIs into the existing fuzz driver, thereby producing higher-quality drivers that are more likely to reach new execution paths or uncover potential vulnerabilities. IV. E VALUATION To evaluate the effectiveness of MASF UZZER, we seek to answer the following research questions: RQ.1 How much more code coverage does MASF UZZER achieve compared to the baselines? RQ.2 Do the multidimensional API sequences contribute to the overall effectiveness of MASF UZZER? RQ.3 Do the coverage-guided time scheduler and fuzz driver mutation strategy contribute to the overall effectiveness of MASF UZZER? RQ.4 What is the impact of different LLMs on the performance of MASF UZZER? RQ.5 Can MASF UZZER find previously unknown bugs in the extensively tested benchmarks? A. Experimental Setup Implementation. We implemented MASF UZZER with over 10K lines of Python code. For static analysis in metainfo extraction, we employed Tree-sitter to parse the abstract syntax tree (AST). Regarding all LLMs, we selected the DeepseekV3 as the default model due to its strong performance and cost efficiency. For fuzzing, we adopted LibFuzzer and performed instrumentation through multiple Sanitizers, including ASan and MSan, to detect runtime program errors. Comparison Baselines. As baselines for comparison, we selected three state-of-the-art library fuzzers: L IB E RA TOR [18], representing traditional (non-LLM-based) library fuzzers, P ROME F UZZ [17] and CKGF UZZER [16], representing LLM-based library fuzzers. Among traditional library fuzzers, L IB E RATOR is the most recent work and demonstrates the best coverage performance. All other traditional library fuzzers have previously been unfavorably compared to L IB E RATOR. For LLM-based library fuzzers, P ROME F UZZ and CKGF UZZER are the most recent works, which significantly
8
TABLE I AVERAGE CODE COVERAGE ACHIEVED BY OUR MASF UZZER AND THE BASELINES P ROME F UZZ , CKGF UZZER AND L IB E RATOR .
Library
Version #Branch #API
c-ares 42ddbc1 cjson 12c4bf1 libpcap f571971 libtiff 67c1cab libvpx 337f4bd zlib 5a82f71 libssh2 694b9d9 libplist 20d5d57 libass 0f37982 libzip 542fc1c libxlsxwriter f6e8305 stormlib 49b619b Average
9166 1048 7698 12414 33070 2906 8728 3922 5798 4406 8806 10630
151 77 78 169 37 81 172 101 45 106 300 76
MASFuzzer P ROME F UZZ 5605.9 858.7 3360.9 5118.3 5279.8 1909.5 974.0 3087.4 3724.1 2595.1 5465.6 3527.7
Code Coverage Comparison Improv CKGF UZZER Improv L IB E RATOR
5285.1 +6.07% 798.7 +7.51% 2880.3 +16.69% 5869.6 -12.80% 4865.5 +8.50% 1334.1 +43.1% 964.2 +1.02% 2889.8 +6.84% 3271.8 +13.82% 2476.2 +4.80% 5443.9 +0.40% 3313.2 +6.47%
-
outperform both OSS-Fuzz-Gen and P ROMPT F UZZ; therefore, we include P ROME F UZZ and CKGF UZZER in our evaluation. For P ROME F UZZ, we adopt its recommended fuzzer, AFL++. For CKGF UZZER, we limit the size of its constructed graph to avoid fuzz driver construction failures caused by exceeding the LLM context length. For L IB E RATOR, both the generation time and the testing time use the recommended optimal configurations. For libraries where no optimal configuration is specified, we uniformly adopt a 6-hour generation and 18hour testing setup. Benchmark Libraries. We selected 12 widely used real-world C libraries for evaluation, including c-ares, cjson, libpcap, libtiff, libvpx, zlib, libplist, libssh2, libass, libzip, libxlsxwriter and stormlib. Among them, eight libraries are from the benchmark suites that are used for evaluating comparison fuzzers [15]–[18], [42]. We also included four additional libraries from the OSS-Fuzz open-source project. We selected these libraries based on the project activity (with code or issue updates within the past month) and the community recognition (with more than 500 GitHub stars). For all selected libraries, we used the latest versions available on GitHub, shown in Table I. Experimental Environment. We evaluated MASF UZZER within a Docker container running Ubuntu 20.04 on an Intel Xeon Gold 5218 @2.30GHz CPU with 128 GB of RAM. All libraries and fuzz drivers were compiled and executed in this environment, and the reported results are the average values obtained from ten independent runs. For comparison, we ran CKGF UZZER and P ROME F UZZ using the same Deepseek-V3 model. Configuration Parameters. In the API sequence construction stage, we set max length L to 10. In the compilation repair stage, the maximum number of repair attempts is 3. For time scheduling, the coverage threshold θ is set to 0.9, the time factor bound β to 0.2, and the time coefficient base B to 2.0. In the fuzz driver mutation stage, the weighting coefficients
-
+8.54%
4743.4 +18.18% 824.4 +4.17% 2963.7 +13.40% 4246.8 +20.52% 3870.3 +36.42% 1731.1 +10.31% 955.7 +1.92% 2759.5 +11.88% 3414.4 +9.07% 2500.4 +3.79% 4106.5 +33.10% 2987.3 +18.09% - +15.07%
Improv
4947.8 +13.30% 758.2 +13.26% 3334.8 +0.78% 3407.6 +50.20% 2973.0 +77.59% 1750.6 +9.08% 905.3 +7.59% 2059.4 +49.92% 3574.8 +4.18% 2271.9 +14.23% 1935.7 +182.36% 2654.1 +32.92% -
+37.95%
(α, β, γ) are set to (0.2, 0.05, 0.01), respectively. Additionally, both API-misuse crash repair and fuzz driver mutation are limited to one attempt per occurrence. B. RQ.1: Comparisons with Baselines We conducted 24-hour fuzzing campaigns on the selected target libraries using fuzz drivers generated by our tool MASF UZZER, as well as baselines P ROME F UZZ, CKGF UZZER and L IB E RATOR. Following the community recommendations [43], we report the average branch coverage for comparison. The overall coverage results are shown in Table I. Here, we list the library version used (Version), the total number of branches (#Branch) and APIs (#APIs) for each library, the branches covered by each tool, and the percentage improvement of our MASF UZZER over the baselines (Improv). Overall Results. Compared to all baselines, MASF UZZER covered a greater number of code branches. On average, MASF UZZER covered 8.54% more code than P ROME F UZZ, reaching up to 16.69% on the library libpcap. Similarly, MASF UZZER achieves 15.07% and 37.95% higher coverage than CKGF UZZER and L IB E RATOR, respectively. It is worth noting that for more complex libraries with a larger number of branches, such as libvpx, and libxlsxwriter, the improvements of MASF UZZER over baselines were more significant. This highlights the effectiveness of MASF UZZER in exploring deep execution branches under complex scenarios. Comparing Results with P ROME F UZZ. MASF UZZER outperforms P ROME F UZZ in 11 out of the 12 target libraries. Adopting a knowledge-driven paradigm, P ROME F UZZ constructs a knowledge base incorporating metadata and documentation constraints, schedules highly correlated API sets based on multidimensional relevance (type, scope, and semantics), and generates drivers assisted by RAG. While it shares similarities with MASF UZZER in leveraging consumer code and type matching to capture API relationships, a critical limitation remains: the extracted loose correlations cannot be directly mapped to effective execution sequences. Further-
9
Fig. 5. Ablation results of MASF UZZER with different dimensions of API sequences.
more, lacking the driver-level time scheduling and mutation strategies inherent to MASF UZZER, P ROME F UZZ is unable to further exploit API relationships to optimize exploration after generation. Instead, it relies on the random scheduling of the underlying fuzzer, rendering the effectiveness of its RAG-generated fuzz drivers heavily dependent on the quality of retrieved documentation. Specifically, P ROME F UZZ demonstrates strong competitiveness in libraries with extensive documentation resources. For instance, in libtiff and libxlsxwriter, which possess 110k+ and 100k+ characters of documentation respectively, P ROME F UZZ achieves 12.80% higher branch coverage than MASF UZZER in the former, and trails by a negligible 0.4% in the latter. Conversely, when applied to zlib, which contains only 8k characters of documentation of API comments, the performance of P ROME F UZZ degrades significantly, resulting in a coverage gap of 43.1% compared to MASF UZZER. Comparing Results with CKGF UZZER. Across all target libraries, MASF UZZER demonstrates consistently higher code coverage than CKGF UZZER. Both are LLM-based fuzzdriver generation frameworks, but CKGF UZZER relies on code knowledge graphs to extract API invocation relationships. This result confirms our observation that the correlation between call graphs and valid API sequences is relatively weak, and only relying on the API invocation relationship is not enough to capture sufficient API sequences. In addition, CKGF UZZER relies solely on the LLM’s semantic understanding to construct fuzz drivers from the retrieved API combinations. Such weak constraints are prone to inducing API misuse. In contrast, MASF UZZER effectively avoids this limitation by deeply modeling both the type constraints and semantic relationships among APIs. Moreover, code knowledge graphs often introduce excessive redundant information. In our evaluation across 12 target libraries, the prompts for 8 libraries exceeded the 64K context window limit due to the inclusion of largescale call graphs. This results in context dilution, which
further hinders the model’s ability to capture critical API invocation information. Collectively, these factors substantially limit CKGF UZZER ’s effectiveness in generating high-quality fuzz drivers. Comparing Results with L IB E RATOR. Across all target libraries, MASF UZZER achieves markedly higher code coverage than L IB E RATOR. Similar to MASF UZZER, L IB E RATOR leverages type matching to establish API dependencies, synthesizes candidate fuzz drivers by traversing API Flow Graphs (AFGs), and applies clustering-based algorithms for driver selection. However, due to its consumer-agnostic design, L IB E RATOR lacks grounding in concrete usage patterns as ground truth and struggles to infer implicit, semantically driven logical dependencies among APIs. As a result, a portion of potentially reachable code paths remains unexplored, preventing L IB E R ATOR from effectively covering certain branches with high fuzzing potential. In terms of LLM cost, the experiment for MASF UZZER takes $49.87, remaining more cost-effective than CKGF UZZER ($67.81). CKGF UZZER incurs substantial expenses due to the inclusion of extremely lengthy call graphs in its prompt context. Conversely, while this exceeds P ROME F UZZ ($11.43), the additional cost is justified by our comprehensive approach: MASF UZZER utilizes multidimensional API sequences to generate more fuzz drivers and employs LLMbased agents for driver mutation and crash analysis. C. RQ.2: Contribution of Different API Sequence Dimensions MASF UZZER adopts three dimensions of API sequences to guide fuzz-driver generation from usage examples, mutationpropagation analysis, and semantic-aware analysis. To evaluate the contribution of each dimension, we conducted an ablation study. Specifically, we developed two additional variant tools: MASF UZZER using only API sequences from usage example (Seque ), MASF UZZER using both API sequences from usage examples and mutation-propagation analysis (Seque +Seqmp ),
10
TABLE II B RANCH COVERAGE OF MASF UZZER WITH AND WITHOUT THE TIME SCHEDULER AND MUTATION STRATEGY.
c-ares cjson libpcap libtiff libvpx
zlib
libssh2 libplist libass libzip stormlib libxlsxwriter
MASF UZZER 5605.9 858.7 3360.9 5118.3 5279.8 1909.5 974.0 3087.4 3724.1 2595.1 3527.7 w/o Time Scheduler 5023.2 801.4 2977.6 4838.0 4783.2 1853.2 923.4 2824.3 3282.2 2421.8 3116.6 w/o Mutation 5414.2 823.9 3315.7 4993.0 4862.4 1800.4 951.8 2977.5 3457.1 2487.0 3339.8
5465.6 4935.7 5291.6
Avg 3458.9 3148.4 3309.5
TABLE III B RANCH COVERAGE ACHIEVED BY MASF UZZER UNDER DIFFERENT MODELS : D EEPSEEK -V3 AND GPT-5.
MASF UZZER-Model c-ares cjson libpcap libtiff libvpx Deepseek-V3 GPT-5
zlib
libssh2 libplist libass libzip stormlib libxlsxwriter
5605.9 858.7 3360.9 5118.3 5279.8 1909.5 974.0 3087.4 3724.1 2595.1 3527.7 5520.8 840.7 3564.9 5134.4 5107.3 1949.9 983.6 3103.9 3881.2 2538.7 3461.3
and compared them with MASF UZZER using all API sequences (All Three Sequences). The results are shown in Figure 5. Overall Results. Across all target libraries, MASF UZZER using all dimensions of API sequences achieves the highest coverage. The variant using API sequences from both usage examples and mutation-propagation analysis ranked second, with an average coverage 5.17% less than MASF UZZER. In contrast, the variant relying solely on API sequences from usage examples performed the worst, with an average coverage 11.55% lower. These results are consistent with our theoretical analysis. Detailed Analysis. Upon further analysis of these subjects, we have the following findings. For libraries that have a larger number of test cases and usage scenarios, such as zlib, using API sequences from usage examples only can achieve good code coverage, which is unsurprising. It is interesting to find that the effectiveness of API sequences via mutationpropagation-grounded mining largely depends on the extent to which the APIs within a library share common data structures. For example, in the cjson library, 73 out of its 78 APIs depend on the cjson structure. This characteristic makes mutation-propagation analysis particularly effective, which can generate complex API sequences that cover nearly all usage scenarios. In contrast, in the c-ares library, most APIs pass complex structures through pointer parameters while returning only simple status or result codes. Of its 152 APIs, only 48 produce return values that can be matched with other APIs’ parameters. In such cases, generating API sequences through semantic-aware analysis becomes necessary. D. RQ.3: Contribution of Time Scheduler and Mutation Strategy In this section, we investigate the contribution of the time scheduler and mutation strategy to the effectiveness of MASF UZZER. To this end, we construct two variants of MASF UZZER by disabling the time scheduler and the mutation strategy, respectively, and conduct an additional case study. In the variant without the time scheduler, each fuzz driver is allocated an equal testing duration. In the variant without the mutation strategy, any fuzz driver that fails to discover
5465.6 5487.1
Avg 3458.9 3464.5
new coverage branches is immediately terminated and is not subjected to further mutation iterations for generating new fuzz drivers. The experimental results are presented in Table II. Overall Results. MASF UZZER with both the time scheduler and mutation strategy enabled achieves higher coverage across all 12 tested libraries. On average, it improves coverage by 9.08% over the variant without the time scheduler and by 4.57% over the variant without the mutation strategy. These results indicate that the combination of coverage-guided time scheduling and fuzz driver mutation not only transforms ineffective fuzz drivers into ones with testing potential, but also efficiently allocates more computational resources to promising fuzz drivers, thereby enabling exploration of deeper program branches. E. RQ.4: Impact of Different LLMs To evaluate the impact of different models on MASF UZZER, we compared the latest released model GPT-5 with DeepSeek-V3—the default model used by MASF UZZER. We measured the code coverage achieved by each model over a 24-hour fuzzing period, and the results are shown in Table III. In addition, we analyzed the style differences in fuzz drivers generated by these models. Impact on Code Coverage. MASF UZZER powered by GPT-5 achieved higher coverage in 8 out of the 12 tested libraries. However, the advantage was marginal, with an average improvement of only 0.16%. In the case of libpcap, where the difference was the largest, GPT-5 exceeded Deepseek-V3 by 6.10%. These findings indicate that, within the context of MASF UZZER, the overall performance of GPT-5 and Deepseek-V3 is largely comparable. Impact on Driver Style. Although their final coverage results were comparable, the styles of the generated drivers differed considerably. GPT-5 tends to produce hierarchical and structured code that explicitly distinguishes multidimensional API sequence invocation paths, emphasizes temporal ordering and dependency management, and adopts a defensive programming paradigm with extensive error handling and fallback mechanisms. In contrast, DeepSeek-V3 follows a concise three-stage structure consisting of initialization, invocation, and cleanup, generating compact linear execution code that
11
missing object deallocation in special cases; in the libtiff library, we detected that the TIFFReadCustomDirectory function lacked a null pointer check, which resulted in a crash when subsequently invoking strlen. Moreover, the minimal triggering API sequence lengths of these bugs range from one to eleven, demonstrating that MASF UZZER is capable of uncovering diverse types of bugs across multiple levels of complexity.
TABLE IV N EW BUGS FOUND BY MASF UZZER
ID Library
Bug Type
Status
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Circular Reference NULL Pointer Dereference NULL Pointer Dereference NULL Pointer Dereference NULL Pointer Dereference Memory Leak Buffer Overflow Memory Leak Circular Reference Use-After-Free Buffer Overflow Buffer Overflow Infinite Loop Buffer Overflow NULL Pointer Dereference Buffer Overflow
Confirmed Fixed Reported Fixed Fixed† Fixed† Fixed† Confirmed† Fixed Fixed Reported Fixed† Fixed† Fixed† Fixed† Fixed†
cjson libtiff libtiff libssh2 libssh2 libssh2 libssh2 libssh2 libplist libplist libplist libxlsxwriter libxlsxwriter libxlsxwriter libxlsxwriter stormlib
static int hostline(LIBSSH2_KNOWNHOSTS *hosts, ,→ const char *host, size_t hostlen, const ,→ char *key, size_t keylen){ 2 while((*key == ' ') || (*key == '\t')) { 3 key++; 4 keylen--; 5 } 6 } 1
Fig. 6. Vulnerable code of a CVE-assigned bug in libssh2.
F. RQ.5: Bug Detection Capability
Case Study. Figure 6 illustrates the buffer-overflow vulnerability detected by MASF UZZER in the libssh2 library. libssh2_knownhost_readline is responsible for parsing individual entries in the SSH client known_hosts file, which calls the hostline function to read a line of text and extract structured information, skipping over empty fields in the process. However, due to the lack of a proper check on keylen, when consecutive empty fields occur, the key pointer can exceed the valid data range, leading to an out-of-bounds memory access and triggering a buffer overflow. API Misuse VS Actual Bug. Table V presents the number of unique crashes detected by MASF UZZER, including those caused by API misuse and actual bugs. In total, MASF UZZER identified 43 unique crashes, of which 27 were API misuses. A thorough analysis of these API misuses revealed that 17 instances involved violations of API documentation, such as passing null pointers, mismatched buffer sizes, and inconsistent parameter types. It is worth noting that due to the lack of built-in input validation in C library, the boundary between API misuse and actual bugs is often blurred. For example, in cases of crashes caused by passing null pointers, the developers of libtiff consider adding assertions to prevent such issues valuable, while the developers of libass believe that the validity of such inputs should be the responsibility of the developers. Given the absence of prior knowledge, these situations cannot be fully determined by the fuzzing framework alone. It is therefore necessary to consult the project documentation and engage in further research and discussions with the library developers to gain a deeper understanding.
We further evaluate the capability of MASF UZZER in detecting real-world bugs and distinguishing true bugs from API misuse. This section presents the discovered vulnerabilities, representative case studies, and an analysis of false positives. Real-world Bug Detection. Table IV summarizes 16 previously unknown bugs discovered by MASF UZZER, 14 of which have already been confirmed and fixed. These bugs span multiple categories, such as null pointer dereference, memory leak, and buffer overflow. For example, in the libssh2 library, MASF UZZER identified a memory leak in the libssh2_knownhost_check function caused by
V. D ISCUSSIONS AND F UTURE D IRECTIONS Data Contamination. With the recent advances in LLMbased library fuzzing, widely tested libraries such as cjson and c-ares are frequently included in fuzzing benchmarks, which may already have a large number of fuzz drivers. When these fuzz drivers appear in the training corpus of LLMs, they may introduce data contamination: the observed coverage advantage might not stem from the novel design of MASF UZZER, but from the model memorization on highcoverage fuzz drivers encountered during training. To mitigate
† Indicates bugs that have been assigned CVE IDs. TABLE V N UMBER OF DETECTED BUGS BY MASF UZZER
Library
UC
MC
RB
CB (FB)
c-ares 4 4 0 0 cjson 4 3 1 1 (0) libpcap 2 2 0 0 libtiff 5 3 2 1 (1) libvpx 3 3 0 0 zlib 1 1 0 0 libssh2 8 3 5 5 (4) libplist 5 2 3 2 (2) libass 2 2 0 0 libzip 1 1 0 0 libxlsxwriter 6 2 4 4 (4) stormlib 2 1 1 1 (1) Total 43 27 16 14 (12) UC: Unique Crash. MC: API Misuse Crash. RB: Reported Bugs. CB: Confirmed Bugs. FB: Fixed Bugs.
focuses on exploring a single API path in depth and relies on a fail-fast error handling strategy. These differences highlight the distinct optimization objectives of the two models in code generation: GPT-5 prioritizes robustness and breadth of coverage, while DeepSeek-V3 emphasizes simplicity and execution efficiency.
12
this issue, we employed the same model and parameters when comparing MASF UZZER with another LLM-based tool, minimizing discrepancies introduced by potential contamination. In comparison with traditional tools, however, this limitation is largely unavoidable. Furthermore, among the ten tested libraries, only eight had appeared in previous benchmarks; we intentionally included four additional libraries that had not been used before, in order to further reduce the risk of contamination. Construction of API Sequences with Complex Branches and Loops. During the construction of multidimensional API sequences, MASF UZZER only produces straight-line API sequences, without any branches or loops. However, when generating fuzer drivers, LLMs can introduce control-flow structures based on these straight-line API sequences. While ignoring such loops and branches in the initial API sequences can lead to incomplete coverage of complex scenarios, this limitation is shared by nearly all existing techniques of automated fuzzdriver generation. Support for Other Programming Languages. MASF UZZER currently supports testing libraries written in C. However, in MASF UZZER, aside from the initial static analysis phase for parsing metainfo, the remaining workflow is largely language-agnostic. Its remaining analysis leverages the static analysis tools of Tree-sitter, which support multiple programming languages. Therefore, it is relatively straightforward to extend MASF UZZER to support other languages. In future work, we plan to support commonly used library programming languages such as C++ and Rust. VI. R ELATED W ORK Automated Fuzz-Driver Generation. Traditional approaches primarily rely on static or dynamic analysis to infer API usage patterns from source code [44], [45]. A significant focus has been on correctly sequencing API calls. For instance, GraphFuzz uses lifecycle-aware data-flow graphs to model API dependencies [12], while RULF traverses API dependency graphs specifically to fuzz Rust libraries [46]. These methods are effective at capturing explicit data-flow constraints, where the output of one API directly serves as the input to another. Other techniques have focused on addressing different aspects of the problem. H OPPER [39] introduces an interpretative fuzzing framework that learns API constraints without requiring prior knowledge. More recent works refine the generation and mutation process; for example, OGHARN [42] composes and filters drivers in an oracle-guided manner, libErator [18] aims to balance testing efficiency and depth, and RIMFuzz [47] dynamically adjusts mutation strategies based on real-time coverage feedback. However, these approaches remain fundamentally constrained by information obtainable through code analysis alone, and often struggle to capture implicit semantic dependencies, idiomatic usage patterns, and hidden preconditions—such as required initialization sequences—that are critical for exercising complex library behaviors. LLM-based Fuzz Driver Generation. The remarkable code comprehension and generation capabilities of Large
Language Models (LLMs) have recently been applied to fuzzdriver generation. P ROMPT F UZZ [15] pioneered an iterative, coverage-guided strategy, using fuzzing feedback to refine LLM prompts and progressively generate better drivers, but it lacks an explicit mechanism for capturing relationships among APIs. To address this context deficit, CKGF UZZER [16] enhances LLM performance with Retrieval-Augmented Generation (RAG), querying a Code Knowledge Graph to provide more library-specific information. While this incorporates more structural data, the caller-callee relationships captured in a knowledge graph do not necessarily represent a valid temporal sequence of API invocations. Similarly, P ROME F UZZ uses a knowledge-driven approach with document-RAG to extract API semantics and select candidate APIs, but it still produces an unordered set without explicit structural constraints and lacks driver scheduling or mutation mechanisms for further optimization. MASF UZZER directly addresses these limitations by providing the LLM with explicit and rich contextual information through its multidimensional API sequences. VII. C ONCLUSION In this paper, we propose a method for high-quality fuzzdriver generation through multidimensional API sequences construction. This approach extracts API usage patterns from the codebase and leverages both API mutation-propagationground and semantic-aware mining to build effective API sequences during fuzz-driver generation. Based on this design, we develop MASF UZZER, a fuzzing framework that integrates a dynamic fuzz driver time scheduler with a coverage-guided fuzz driver mutation strategy. We evaluated MASF UZZER on 12 real-world libraries, and the results demonstrate that it outperforms existing tools in terms of code coverage while successfully detecting 16 previously unknown bugs in the extensively tested libraries. Overall, MASF UZZER is capable of generating higher-quality fuzz drivers and provides a general and efficient solution for library fuzzing. DATA AVAILABILITY The data and source code used in this paper are available at https://anonymous.4open.science/r/ano-3545/. R EFERENCES [1] A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “Afl++: Combining incremental steps of fuzzing research,” in 14th USENIX Workshop on Offensive Technologies (WOOT 20). USENIX Association, 2020. [Online]. Available: https://www.usenix.org/conference/woot20/present ation/fioraldi [2] K. Serebryany, “Continuous fuzzing with libfuzzer and addresssanitizer,” in IEEE Cybersecurity Development Conference (SecDev), 2016. [3] M. Böhme, V. J. M. Manès, and S. K. Cha, “Boosting fuzzer efficiency: An information theoretic perspective,” in ACM Joint Meeting on Foundations of Software Engineering (FSE). ACM, 2020. [4] V. J. Manes, H. Han, C. Han, S. K. Cha, M. Egele, E. J. Schwartz, and M. Woo, “The art, science, and engineering of fuzzing: A survey,” arXiv preprint arXiv:1812.00140, 2018. [5] S. B. Chafjiri, P. Legg, J. Hong, and M.-A. Tsompanas, “Vulnerability detection through machine learning-based fuzzing: A systematic review,” Computers & Security, vol. 143, p. 103903, 2024. [6] K. Ispoglou, D. Austin, V. Mohan, and M. Payer, “{FuzzGen}: Automatic fuzzer generation,” in 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 2271–2287.
13
[7] Y. Liu, Y. Wang, X. Jia, Z. Zhang, and P. Su, “Afgen: Whole-function fuzzing for applications and libraries,” in 2024 IEEE Symposium on Security and Privacy (SP). IEEE, 2024, pp. 1901–1919. [8] K. Serebryany, “OSS-Fuzz: Google’s continuous fuzzing service for open source software,” in USENIX Security Symposium, 2017. [9] J. Liu, R. Liang, X. Zhu, Y. Zhang, Y. Liu, and Q. Liu, “Llm4tdg: testdriven generation of large language models based on enhanced constraint reasoning,” Cybersecurity, vol. 8, no. 1, p. 32, 2025. [10] B. Jeong, J. Jang, H. Yi, J. Moon, J. Kim, I. Jeon, T. Kim, W. Shim, and Y. H. Hwang, “Utopia: Automatic generation of fuzz driver using unit tests,” in 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 2676–2692. [11] D. Babić, S. Bucur, Y. Chen, F. Ivančić, T. King, M. Kusano, C. Lemieux, L. Szekeres, and W. Wang, “Fudge: fuzz driver generation at scale,” in Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2019, pp. 975–985. [12] H. Green and T. Avgerinos, “Graphfuzz: Library api fuzzing with lifetime-aware dataflow graphs,” in Proceedings of the 44th International Conference on Software Engineering, 2022, pp. 1070–1081. [13] S. Mallissery and Y.-S. Wu, “Demystify the fuzzing methods: A comprehensive survey,” ACM Computing Surveys, vol. 56, no. 3, pp. 71:1–71:38, 2023. [14] D. Liu, O. Chang, J. metzman, M. Sablotny, and M. Maruseac, “OSS-Fuzz-Gen: Automated Fuzz Target Generation,” May 2024. [Online]. Available: https://github.com/google/oss-fuzz-gen [15] Y. Lyu, Y. Xie, P. Chen, and H. Chen, “Prompt fuzzing for fuzz driver generation,” in Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 3793–3807. [16] H. Xu, W. Ma, T. Zhou, Y. Zhao, K. Chen, Q. Hu, Y. Liu, and H. Wang, “Ckgfuzzer: Llm-based fuzz driver generation enhanced by code knowledge graph,” in 2025 IEEE/ACM 47th International Conference on Software Engineering: Companion Proceedings (ICSECompanion). IEEE, 2025, pp. 243–254. [17] Y. Liu, J. Deng, X. Jia, Y. Wang, M. Wang, L. Huang, T. Wei, and P. Su, “Promefuzz: A knowledge-driven approach to fuzzing harness generation with large language models,” in Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’25. New York, NY, USA: Association for Computing Machinery, 2025, p. 1559–1573. [Online]. Available: https://doi.org/10.1145/3719027.3765222 [18] F. Toffalini, N. Badoux, Z. Tsinadze, and M. Payer, “Liberating libraries through automated fuzz driver generation: Striking a balance without consumer code,” Proceedings of the ACM on Software Engineering, vol. 2, no. FSE, pp. 2123–2145, 2025. [19] M. Böhme, C. Cadar, and A. Roychoudhury, “Fuzzing: Challenges and reflections,” IEEE Software, vol. 38, no. 3, pp. 79–86, 2020. [20] X. Zhao, H. Qu, J. Xu, X. Li, W. Lv, and G.-G. Wang, “A systematic review of fuzzing,” Soft Computing, vol. 28, no. 6, pp. 5493–5522, 2024. [21] A. Fioraldi, A. Mantovani, D. Maier, and D. Balzarotti, “Dissecting american fuzzy lop: a fuzzbench evaluation,” ACM transactions on software engineering and methodology, vol. 32, no. 2, pp. 1–26, 2023. [22] V.-T. Pham, M. Böhme, A. E. Santosa, A. R. Căciulescu, and A. Roychoudhury, “Smart greybox fuzzing,” IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1980–1997, 2019. [23] J. Wang, B. Chen, L. Wei, and Y. Liu, “Superion: Grammar-aware greybox fuzzing,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 724–735. [24] LLVM Project, “Libfuzzer — a library for coverage-guided fuzz testing,” https://llvm.org/docs/LibFuzzer.html, accessed: 2026-03-29. [25] J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat et al., “Gpt-4 technical report,” arXiv preprint arXiv:2303.08774, 2023. [26] B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, R. Sauvestre, T. Remez et al., “Code llama: Open foundation models for code,” arXiv preprint arXiv:2308.12950, 2023. [27] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. D. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021. [28] Y. Cheng, H. J. Kang, L. K. Shar, C. Dong, Z. Shi, S. Lv, and L. Sun, “Towards reliable llm-driven fuzz testing: Vision and road ahead,” arXiv preprint arXiv:2503.00795, 2025. [29] J. Wang and Y. Chen, “A review on code generation with llms: Application and evaluation,” in 2023 IEEE International Conference on Medical Artificial Intelligence (MedAI). IEEE, 2023, pp. 284–289.
[30] M. L. Siddiq, J. C. Da Silva Santos, R. H. Tanvir, N. Ulfat, F. Al Rifat, and V. Carvalho Lopes, “Using large language models to generate junit tests: An empirical study,” in Proceedings of the 28th international conference on evaluation and assessment in software engineering, 2024, pp. 313–322. [31] M. Schäfer, S. Nadi, A. Eghbali, and F. Tip, “An empirical evaluation of using large language models for automated unit test generation,” IEEE Transactions on Software Engineering, vol. 50, no. 1, pp. 85–105, 2024. [32] J. Liu, S. Lee, E. Losiouk, and M. Böhme, “Can llm generate regression tests for software commits?” arXiv preprint arXiv:2501.11086, 2025. [33] C. S. Xia and L. Zhang, “Keep the conversation going: Fixing 162 out of 337 bugs for $0.42 each using chatgpt,” arXiv preprint arXiv:2304.00385, 2023. [34] C. S. Xia, M. Paltenghi, J. L. Tian, M. Pradel, and L. Zhang, “Fuzz4all: Universal fuzzing with large language models,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, 2024, pp. 126:1–126:13. [35] R. Meng, M. Mirchev, M. Böhme, and A. Roychoudhury, “Large language model guided protocol fuzzing,” in Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS), vol. 2024, 2024. [36] J. Hu, Q. Zhang, and H. Yin, “Augmenting greybox fuzzing with generative ai,” arXiv preprint arXiv:2306.06782, 2023. [37] J. Eom, S. Jeong, and T. Kwon, “Fuzzing javascript interpreters with coverage-guided reinforcement learning for llm-based mutation,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 1656–1668. [38] Y. Deng, C. S. Xia, H. Peng, C. Yang, and L. Zhang, “Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models,” in Proceedings of the 32nd ACM SIGSOFT international symposium on software testing and analysis, 2023, pp. 423–435. [39] P. Chen, Y. Xie, Y. Lyu, Y. Wang, and H. Chen, “Hopper: Interpretative fuzzing for libraries,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023, pp. 1600–1614. [40] X. Zhu, S. Wen, S. Camtepe, and Y. Xiang, “Fuzzing: A survey for roadmap,” ACM Computing Surveys (CSUR), vol. 54, no. 11s, pp. 1–36, 2022. [41] M. Böhme, V.-T. Pham, and A. Roychoudhury, “Coverage-based greybox fuzzing as markov chain,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 1032–1043. [42] G. Sherman and S. Nagy, “No harness, no problem: Oracle-guided harnessing for auto-generating c api fuzzing harnesses,” in 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE Computer Society, 2025, pp. 165–177. [Online]. Available: https://doi.org/10.1109/ICSE55347.2025.00239 [43] G. Klees, A. Ruef, B. Cooper, S. Wei, and M. Hicks, “Evaluating fuzz testing,” in Proceedings of the 2018 ACM SIGSAC conference on computer and communications security, 2018, pp. 2123–2138. [44] Q. Yan, M. Huang, H. Cao, and S. Lu, “Sok: From systematization to best practices in fuzz driver generation,” in Australasian Conference on Information Security and Privacy. Springer, 2025, pp. 348–368. [45] Y. Zhang, J. Wu, and H. Xu, “Rumono: Fuzz driver synthesis for rust generic apis,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 6, pp. 169:1–169:28, 2025. [46] J. Jiang, H. Xu, and Y. Zhou, “Rulf: Rust library fuzzing via api dependency graph traversal,” in 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2021, pp. 581–592. [47] X. Wang and L. Zhao, “Rimfuzz: real-time impact-aware mutation for library api fuzzing,” Journal of King Saud University Computer and Information Sciences, vol. 37, no. 4, p. 52, 2025.