Pith. sign in

REVIEW 2 major objections 9 minor 48 references

Thinking More, Harnessing Better: State Machine Guided Harness Automatic Generation with Project Digestion and Workflow Decomposition

T0 review · 2 major / 9 minor · reviewed 2026-07-09 · glm-5.2

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Decomposed LLM harness generation finds 7 new bugs in fuzzed C projects

desk verdict Solid LLM harness generator with real bugs found, but headline coverage numbers are confounded by harness count read the letter →

arxiv 2607.07007 v1 pith:32PDHRTS submitted 2026-07-08 cs.CR cs.SE

Xing Zhang , Zikang Huang , Gang Yang , CongChong Wang , Lu Liu , Bin Yin , Mingyi Wang , Ziquan Zhao
show 4 more authors
Min Li Zhenyu Chen Bo Wu Lingyun Ying
This is my paper · ORCID
classification cs.CRcs.SE
keywords fuzzharnessgenerationLLMcodedataflowanalysisstructuralflowgraphstagedrollbackfunctiontripletgray-boxfuzzingCprogramsecurity
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that the quality bottleneck in LLM-generated fuzz harnesses is not the model's raw coding ability but two upstream failures: picking the wrong functions to test together, and asking the model to write an entire harness in one shot. SynapseFlow addresses both. First, it builds a Structural Flow Graph (SFG) — a directed graph whose nodes are data-structure types and whose edges are functions that consume one structure and emit another. By traversing this graph, the system extracts Function Triplets: minimal, self-contained groups anchored by a single input-stream function, plus the process functions and lifecycle helpers that share its data structures. This replaces ad-hoc function selection with dataflow-grounded grouping. Second, it decomposes harness synthesis into four sequential stages — API documentation, local snippet stitching, rough assembly, and final optimization — each individually verifiable. A staged rollback algorithm retries failed stages from earlier checkpoints rather than restarting the whole generation, which the authors prove raises compound success probability above both single-shot and linear-retry strategies. Evaluated on 25 real-world C projects, harnesses generated this way achieve 1.7–4.3× higher branch coverage and 1.4–1.8× higher bug-detection rates than three state-of-the-art tools, and surfaced 7 previously unreported bugs (5 CVE-assigned) in projects already under continuous fuzzing.

What carries the argument

Structural Flow Graph (SFG): directed graph where nodes are structure types (or a null node) and edges are functions transforming one structure into another. Function Triplet (FT): an ordered triplet (I, P, H) — one Input Stream Function, a set of Process Functions, a set of Helper Functions — extracted per ISF from the SFG via forward/backward dataflow reachability. Staged rollback algorithm: a four-stage pipeline (documentation, snippet stitching, rough assembly, optimization) where stage-4 failures trigger incremental rollback to stage 3, then stage 2, then stage 1, with a theoretical proof that compound success probability exceeds both single-shot and linear-retry generation.

What would settle it

If one replaced the SFG-based function grouping with random or call-graph-based grouping while keeping the staged rollback pipeline identical, and coverage dropped by the ~30% the ablation reports, then the SFG — not the rollback — is the primary coverage driver. Conversely, if one kept the SFG but replaced the four-stage pipeline with monolithic generation and coverage dropped by ~47%, then the staged decomposition is the primary driver. The ablation already tests both, and the results suggest both contribute substantially, with staged decomposition contributing more.

Watch

Extended reading notes

Core claim

The central object is the Structural Flow Graph: a representation of inter-procedural data dependencies via shared structure types, not call edges. The paper shows that when function grouping for harness generation is grounded in this graph rather than in call-graph proximity or API-level heuristics, the resulting harnesses correctly channel fuzzer inputs through deep data-transformation chains that prior methods systematically miss. Combined with staged decomposition and rollback — which the authors formally show improves compound success probability over monolithic generation — this yields both broader coverage and lower hallucination rates. The 7 new bugs found in continuously fuzzed, CVE

Load-bearing premise

The staged rollback mechanism assumes that when a final harness fails compilation or basic execution, the error originates in a later generation stage and can be fixed by regenerating from an earlier stage's output. If the root cause is a structural flaw in the dataflow graph or function triplet itself — for example, a function misclassified as an input-stream function — then rolling back and regenerating code from the same flawed grouping will reproduce the same class of错误.

Editorial extensions

If this is right

  • If dataflow-grounded function grouping is the key driver of coverage gains, then any fuzz-harness generator — LLM-based or not — should benefit from constructing an SFG before selecting targets, suggesting the graph construction step is separable and composable with other generation backends.
  • The staged rollback formalism (Equations 1–3) is domain-agnostic: any multi-step LLM code-generation pipeline with per-stage validation could adopt the same rollback strategy to improve compound success rates, potentially extending beyond fuzzing to test generation, refactoring, or migration tasks.
  • The finding that 7 new bugs were found in projects under years of continuous fuzzing suggests that existing fuzzing infrastructure has systematic blind spots around functions outside standard API target sets — and that dataflow-guided target selection can systematically surface them.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The SFG's reliance on tree-sitter for syntax parsing (rather than full dataflow analysis) means the approach may degrade on projects with heavy macro usage or indirect function dispatch — the paper acknowledges this for lcms and dropbear. A natural extension would be to substitute a more precise parser for the SFG construction step while keeping the downstream pipeline unchanged, potentially recov
  • The rollback algorithm assumes intermediate-stage outputs are not themselves the source of semantic error. If the SFG or FT extraction contains a structural flaw (e.g., misclassifying an ISF), rolling back to regenerate code from the same flawed triplet will not escape the error — the system would need a feedback path that revisits the grouping phase, which the current architecture does not provid
  • The three-function-category model (ISF/PRF/HPF) is sufficient for C data-processing libraries but may not generalize cleanly to C++ object-oriented initialization patterns or stateful protocol implementations where initialization is spread across constructors and state machines — the paper explicitly flags these as out of scope, suggesting the taxonomy itself is a load-bearing design choice that l
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 9 minor

Summary. The paper presents SynapseFlow, an LLM-based automatic fuzz harness generator for C projects. The approach has two phases: (1) dataflow-aware function aggregation, which constructs a Structural Flow Graph (SFG) and extracts Function Triplets (FTs) — minimal, coherent function groups anchored by Input Stream Functions (ISFs); and (2) harness generation via a four-stage decomposition (documentation, snippet stitching, rough assembly, optimization) governed by a staged rollback algorithm. The evaluation covers 25 real-world C projects, comparing against OSS-Fuzz-Gen, CKGFuzzer, and PromeFuzz on branch coverage, bug detection, and efficiency, with an ablation study isolating the SFG and staged rollback contributions. The paper reports 7 previously unreported bugs (5 CVEs). The core technical ideas — dataflow-grounded function grouping and decomposed generation with rollback — are well-motivated and the experimental design is largely rigorous, including the controlled bug-detection comparison (RQ2) and the ablation (RQ6). However, the headline coverage comparison (RQ1) conflates per-harness quality with harness quantity, which undermines the central comparative claim and must be addressed.

Significance. Automated harness generation is a practically important problem, and the paper's combination of lightweight static dataflow analysis with LLM-driven semantic reasoning and staged rollback is a reasonable and novel architectural contribution. The discovery of 7 previously unreported bugs (5 CVEs) on extensively fuzzed projects is a strong practical result. The ablation study (Table 9) properly isolates the SFG and staged decomposition components within SynapseFlow's own scope. The theoretical proof in Appendix A, while simple, provides a principled (if idealized) justification for the rollback mechanism. The artifact availability (encrypted executable, scripts, generated harnesses) supports reproducibility, though full source code is withheld pending acceptance.

major comments (2)
  1. §4.1.1–4.1.3, Table 4, Table 11: The headline coverage comparison aggregates branch coverage across ALL harnesses each tool generates per project. Table 11 reveals that SynapseFlow generates 3–13× more harnesses than baselines (e.g., sqlite3: 603 vs. 45/112/104; cjson: 150 vs. 58/40/64; libtiff: 353 vs. 128/153/128). This is structural: SynapseFlow targets all functions via FT extraction (Table 3), while OSS-Fuzz-Gen targets single functions and CKGFuzzer/PromeFuzz target API-only functions. The coverage ratio is therefore confounded by scope. The paper acknowledges this scope difference in §4.1.3 but the headline numbers ('3.07×, 1.71×, 4.26× higher branch coverage') do not disclose it. Per-harness coverage efficiency may actually be lower for SynapseFlow: for sqlite3, 28063 branches / 603 harnesses ≈ 47 branches/harness vs. OSS-Fuzz-Gen's 16879/45 ≈ 375 branches/harness. The authors' R
  2. §4.1.3: The paper states that baselines 'achieve high function counts but fail to exercise internal control-flow paths' because they perform 'superficial invocations without properly routing external fuzz inputs.' This is a strong claim about per-harness quality. If true, it should be demonstrable via a per-harness or per-function-coverage-normalized metric. The current presentation does not provide this. Adding a normalized comparison (e.g., median branches covered per harness, or coverage restricted to the intersection of functions targeted by all tools) would either confirm the authors' explanation or reveal that the aggregate advantage is primarily a scope effect. This is load-bearing because the paper's framing positions SynapseFlow as generating higher-quality harnesses, not merely more harnesses.
minor comments (9)
  1. The title in the manuscript body ('Thinking More, Harnessing Better: Automatic Harness Generation with Dataflow Aggregation and Workflow Decomposition') differs from the title in the paper_id metadata ('State Machine Guided Harness Automatic Generation with Project Digestion and Workflow Decomposition'). These should be reconciled.
  2. Abstract states '5 assigned CVEs' and §1 states '4 assigned CVEs'; Table 6 lists 5 CVE IDs. The inconsistency in §1 should be corrected.
  3. Appendix A, Eqs. (1)–(3): The proof assumes stage independence (P_i) and a compensation success probability c that is introduced without derivation. The result P_rollback > P_seq > P_o is straightforward under these assumptions but the independence assumption is strong. A brief acknowledgment that real stages are not independent would improve honesty.
  4. §3.2.1: The three-prompt voting scheme is described, but no empirical validation of its accuracy (e.g., precision/recall on a labeled subset) is provided. A sentence or two of evidence would strengthen the claim that it 'significantly improves accuracy.'
  5. Table 4: The 'Aver. Rate(%)' row shows 46.9, 55.0, 61.3, 83.3. It is unclear whether this is a simple mean across projects, a coverage-weighted average, or a harness-count-weighted average. The caption should specify.
  6. Figure 6: The x-axis labels appear to be corrupted/garbled (unicode escape sequences). Project names are unreadable. This figure needs to be regenerated.
  7. §5.3: 'Limitations for Stateful Targets' and the preceding paragraph on 'Semantic Validation' overlap significantly. These should be merged.
  8. Table 3: The 'Feedback' row lists SynapseFlow as 'Iterative' and baselines as 'None.' The staged rollback is iterative in the sense of retrying stages, but it is not feedback-driven in the sense of incorporating runtime coverage feedback into generation. The label could be more precise (e.g., 'Retry-based' or 'Compilation-guided').
  9. §4.4.3: The claim that 'excessive prompt length induces quadratic scaling in Time-To-First-Token' is stated without citation. A reference or a brief empirical justification (e.g., measured TTFT vs. prompt length) would suffice.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity detected; derivation chain is self-contained with external validation

full rationale

The paper's derivation chain has no circular steps. (1) The theoretical proof in Appendix A is a standard conditional probability argument: it assumes P_i > P_o^{1/n} (decomposition makes each sub-task easier) and derives P_rollback > P_seq > P_o using elementary probability calculus. The assumption is a reasonable modeling premise, not a result defined in terms of the conclusion. (2) The SFG construction, FT extraction (Algorithm 1), and staged rollback (Algorithm 2) are methodological procedures with no definitional circularity—outputs (FTs, harnesses) are not defined in terms of the metrics used to evaluate them. (3) The evaluation uses 25 external open-source projects, three external baseline tools, and standard measurement instruments (llvm-cov, libFuzzer). No metric is defined in terms of SynapseFlow's own outputs. (4) The ablation study (Table 9) compares SFG vs. heuristic grouping and staged vs. monolithic generation within the same framework—proper experimental controls, not definitional reductions. (5) No load-bearing self-citations were found; the paper's central claims rest on independent experimental evidence. The skeptic's concern about harness-count confounding in coverage ratios is a validity/methodology issue (comparing aggregate coverage across tools with different harness counts), not a circularity issue—the coverage metric itself is externally measured and not defined in terms of SynapseFlow's inputs.

Assumptions & free parameters 3 free parameters · 3 assumptions · 2 invented entities

The framework relies on a few hand-tuned engineering parameters (retry thresholds, token caps) and the core domain assumption that its three-function classification scheme captures the necessary semantics for harness generation.

free parameters (3)
  • Max retries per stage (regen threshold) = 3
    Algorithm 2 sets the threshold for rolling back to an earlier stage at 3 failed attempts. This is a hand-tuned parameter.
  • Token cap per stage = 8K
    Mentioned in Section 4.4 as a strict 8K token cap per stage to control latency. This is an engineering choice.
  • Fuzzing campaign duration = 24 hours
    Standard experimental parameter for fuzzing evaluations, chosen by the authors.
assumptions (3)
  • domain assumption Functions can be accurately classified into ISF, PRF, and HPF categories using a hybrid of tree-sitter syntax analysis and LLM semantic reasoning.
    Section 3.2.1 assumes this classification is sufficient to capture all relevant data-processing functions for harness generation.
  • domain assumption LLM hallucinations and errors in monolithic generation can be effectively contained by decomposing the task into sequential, verifiable stages with rollback.
    Section 3.3 assumes that staged decomposition with rollback is a superior strategy to single-prompt generation or LLM-based repair.
  • standard math Branch coverage and bug detection rates are valid proxies for harness quality.
    Standard assumption in fuzzing research, used throughout the evaluation (Section 4).
invented entities (2)
  • Structural Flow Graph (SFG) independent evidence
    purpose: A directed graph modeling how data structures flow between functions, used to identify function dependencies.
    The SFG is constructed via static analysis and LLM reasoning (Section 3.2.2) and its quality is empirically evaluated in RQ6 (Table 9).
  • Function Triplet (FT) independent evidence
    purpose: An ordered triplet (ISF, PRF, HPF) representing a minimal, self-contained data processing unit for harness generation.
    FTs are extracted from the SFG via Algorithm 1 and their utility is validated by the coverage and bug detection results.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Thinking More, Harnessing Better: State Machine Guided Harness Automatic Generation with Project Digestion and Workflow Decomposition." pith.science (2026). https://pith.science/paper/32PDHRTS

@misc{pith2026260707007,
  author       = {Pith},
  title        = {Pith review of: Thinking More, Harnessing Better: State Machine Guided Harness Automatic Generation with Project Digestion and Workflow Decomposition},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/32PDHRTS}},
  note         = {Machine review of arXiv:2607.07007}
}
abstract

High-quality fuzz harnesses are essential for effective gray-box fuzzing. While Large Language Models (LLMs) offer promise for automating this task, existing one-turn generation methods suffer from hallucinations and inadequate coverage due to coarse-grained function targeting and misaligned generation workflows. We present SynapseFlow, an automatic harness generator that addresses these limitations through two key innovations: dataflow-aware function aggregation and a staged, rollback-enabled generation workflow decomposition. SynapseFlow first analyzes source code to construct Structural Flow Graphs and extract coherent Function Triplets. It then synthesizes harnesses via a decomposed four-stage process governed by a staged rollback algorithm to ensure correctness. We evaluated SynapseFlow on 25 real-world open-source software projects. The experimental results indicate that SynapseFlow outperforms state-of-the-art tools (OSS-Fuzz-Gen, CKGFuzzer, PromeFuzz), achieving 3.07$\times$, 1.71$\times$, and 4.26$\times$ higher branch coverage, and 1.77$\times$, 1.51$\times$, and 1.36$\times$ higher bug detection rates, respectively. Most importantly, SynapseFlow discovered 7 previously unreported bugs (5 assigned CVEs), demonstrating its practical effectiveness in real-world bug discovery.

Figures

Figures reproduced from arXiv: 2607.07007 by the authors.

Figure 1
Figure 1. A comparison of harnesses generated by distinct approaches for [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Structural flow graph for j40 depicting data struc [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The workflow of SynapseFlow. • Nodes (𝑉 ): Each node represents a unique structure type. A special “(null)” node represents the absence of an input/out￾put structure. • Edges (𝐸): A directed edge 𝑒 = ⟨𝑛𝑖𝑛, 𝑛𝑜𝑢𝑡⟩ ∈ 𝐸 represents a function 𝑓 that consumes an input structure 𝑛𝑖𝑛 and produces an output structure 𝑛𝑜𝑢𝑡 . The edge is labeled with 𝑓 . By processing all project functions, we construct the complete SFG. For o… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Structural processing snippet generation for the [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Rough code assembly for the j40 project (Stage 3). Structural snippets are iteratively merged following the dataflow order. Stage 4: Code Optimization and Harness Transformation. The goal is to convert the rough prototype into a final, fuzzing￾ready harness. The LLM pe…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 48 canonical work pages

  1. [1]

    Sok: Eternal war in memory

    Laszlo Szekeres, Mathias Payer, Tao Wei, and Dawn Song. Sok: Eternal war in memory. In2013 IEEE Symposium on Security and Privacy, SP ’13, page 48–62, USA, 2013. IEEE Computer Society

    work page 2013

  2. [2]

    The art, science, and engineering of fuzzing: A survey.IEEE Transactions on Software Engineering, 47(11):2312–2331, 2019

    Valentin JM Manès, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J Schwartz, and Maverick Woo. The art, science, and engineering of fuzzing: A survey.IEEE Transactions on Software Engineering, 47(11):2312–2331, 2019

    work page 2019

  3. [3]

    Continuous fuzzing with libfuzzer and addresssanitizer

    Kosta Serebryany. Continuous fuzzing with libfuzzer and addresssanitizer. In 2016 IEEE Cybersecurity Development (SecDev), pages 157–157. IEEE, 2016

    work page 2016

  4. [4]

    Llm-based test-driven interactive code generation: User study and empirical evaluation.IEEE Transactions on Software Engineering, 2024

    Sarah Fakhoury, Aaditya Naik, Georgios Sakkas, Saikat Chakraborty, and Shu- vendu K Lahiri. Llm-based test-driven interactive code generation: User study and empirical evaluation.IEEE Transactions on Software Engineering, 2024

    work page 2024

  5. [5]

    OSS-Fuzz-Gen: Automated Fuzz Target Generation, May 2024

    Dongge Liu, Oliver Chang, Jonathan metzman, Martin Sablotny, and Mihai Maruseac. OSS-Fuzz-Gen: Automated Fuzz Target Generation, May 2024

    work page 2024

  6. [6]

    Understanding large language model based fuzz driver generation.arXiv e-prints, pages arXiv–2307, 2023

    Cen Zhang, Mingqiang Bai, Yaowen Zheng, Yeting Li, Wei Ma, Xiaofei Xie, Yuekang Li, Limin Sun, and Yang Liu. Understanding large language model based fuzz driver generation.arXiv e-prints, pages arXiv–2307, 2023

    work page 2023

  7. [7]

    How effective are they? exploring large language model based fuzz driver generation

    Cen Zhang, Yaowen Zheng, Mingqiang Bai, Yeting Li, Wei Ma, Xiaofei Xie, Yuekang Li, Limin Sun, and Yang Liu. How effective are they? exploring large language model based fuzz driver generation. In33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 1223–1235, 2024

    work page 2024

  8. [8]

    Prompt fuzzing for fuzz driver generation

    Yunlong Lyu, Yuxuan Xie, Peng Chen, and Hao Chen. Prompt fuzzing for fuzz driver generation. In2024 ACM SIGSAC Conference on Computer and Communi- cations Security, pages 3793–3807, 2024

    work page 2024

Show all 48 references
  1. [9]

    Ckgfuzzer: Llm-based fuzz driver generation enhanced by code knowledge graph

    Hanxiang Xu, Wei Ma, Ting Zhou, Yanjie Zhao, Kai Chen, Qiang Hu, Yang Liu, and Haoyu Wang. Ckgfuzzer: Llm-based fuzz driver generation enhanced by code knowledge graph. In47th International Conference on Software Engineering: Companion Proceedings, ICSE ’25, page 243–254. IEEE...

    2025

  2. [10]

    An empirical study of fuzz harness degradation.arXiv preprint arXiv:2505.06177, 2025

    Philipp Görz, Joschua Schilling, Thorsten Holz, and Marcel Böhme. An empirical study of fuzz harness degradation.arXiv preprint arXiv:2505.06177, 2025

    2025 arXiv

  3. [11]

    Understanding the planning of llm agents: A survey.arXiv preprint arXiv:2402.02716, 2024

    Xu Huang, Weiwen Liu, Xiaolong Chen, Xingmei Wang, Hao Wang, Defu Lian, Yasheng Wang, Ruiming Tang, and Enhong Chen. Understanding the planning of llm agents: A survey.arXiv preprint arXiv:2402.02716, 2024

    2024 arXiv

  4. [12]

    Promefuzz: A knowledge-driven approach to fuzzing harness generation with large language models

    Yuwei Liu, Junquan Deng, Xiangkun Jia, Yanhao Wang, Minghua Wang, Lin Huang, Tao Wei, and Purui Su. Promefuzz: A knowledge-driven approach to fuzzing harness generation with large language models. In2025 ACM SIGSAC Conference on Computer and Communications Security, CCS ’25, p...

    2025

  5. [13]

    In- telligen: Automatic driver synthesis for fuzz testing

    Mingrui Zhang, Jianzhong Liu, Fuchen Ma, Huafeng Zhang, and Yu Jiang. In- telligen: Automatic driver synthesis for fuzz testing. In2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pages 318–327. IEEE, 2021

    2021

  6. [14]

    Fudge: fuzz driver generation at scale

    Domagoj Babić, Stefan Bucur, Yaohui Chen, Franjo Ivancic, Tim King, Markus Kusano, Caroline Lemieux, László Szekeres, and Wei Wang. Fudge: fuzz driver generation at scale. pages 975–985, 08 2019

    2019

  7. [15]

    {FuzzGen}: Automatic fuzzer generation

    Kyriakos Ispoglou, Daniel Austin, Vishwath Mohan, and Mathias Payer. {FuzzGen}: Automatic fuzzer generation. In29th USENIX Security Symposium (USENIX Security 20), pages 2271–2287, 2020

    2020

  8. [16]

    https://github.com/lifthrasiir/j40, Accessed: 2024

    j40. https://github.com/lifthrasiir/j40, Accessed: 2024

    2024

  9. [17]

    sitter Contributors

    T. sitter Contributors. Tree-sitter: An incremental parsing system for program- ming tools, 2025

    2025

  10. [18]

    Hopper: Interpretative fuzzing for libraries

    Peng Chen, Yuxuan Xie, Yunlong Lyu, Yuxiao Wang, and Hao Chen. Hopper: Interpretative fuzzing for libraries. pages 1600–1614, 11 2023

    2023

  11. [19]

    Afgen: Whole-function fuzzing for applications and libraries

    Yuwei Liu, Yanhao Wang, Xiangkun Jia, Zheng Zhang, and Purui Su. Afgen: Whole-function fuzzing for applications and libraries. In2024 IEEE Symposium on Security and Privacy (SP), pages 1901–1919. IEEE, 2024

    1901

  12. [20]

    Sok: Prudent evaluation practices for fuzzing

    Moritz Schloegel, Nils Bars, Nico Schiller, Lukas Bernhard, Tobias Scharnowski, Addison Crump, Arash Ale-Ebrahim, Nicolai Bissantz, Marius Muench, and Thorsten Holz. Sok: Prudent evaluation practices for fuzzing. In2024 IEEE Symposium on Security and Privacy (SP), pages 1974–1...

    1974

  13. [21]

    https://issues.oss-fuzz.com, Accessed: Jan 2026

    OSS-Fuzz Tracker. https://issues.oss-fuzz.com, Accessed: Jan 2026

    2026

  14. [22]

    Confusing value with enumeration: Studying the use of{CVEs} in academia

    Moritz Schloegel, Daniel Klischies, Simon Koch, David Klein, Lukas Gerlach, Malte Wessels, Leon Trampert, Martin Johns, Mathy Vanhoef, Michael Schwarz, et al. Confusing value with enumeration: Studying the use of{CVEs} in academia. In34th USENIX Security Symposium (USENIX Secu...

    2025

  15. [23]

    Deepseek-v3 technical report

    DeepSeek-AI. Deepseek-v3 technical report. Technical report, DeepSeek-AI, 2025

    2025

  16. [24]

    Claude 3.5 series update, 2024

    Anthropic. Claude 3.5 series update, 2024

    2024

  17. [25]

    A compari- son of deepseek and other llms.arXiv preprint, arXiv:2502.03688, 2025

    Tianchen Gao, Jiashun Jin, Zheng Tracy Ke, and Gabriel Moryoussef. A compari- son of deepseek and other llms.arXiv preprint, arXiv:2502.03688, 2025

    2025

  18. [26]

    Winnie: Fuzzing windows applications with harness synthesis and fast cloning

    Jinho Jung, Stephen Tong, Hong Hu, Jungwon Lim, Yonghwi Jin, and Taesoo Kim. Winnie: Fuzzing windows applications with harness synthesis and fast cloning. In2021 Network and Distributed System Security Symposium (NDSS 2021), 2021

    2021

  19. [27]

    APICraft: Fuzz driver generation for closed-source SDK libraries

    Cen Zhang, Xingwei Lin, Yuekang Li, Yinxing Xue, Jundong Xie, Hongxu Chen, Xinlei Ying, Jiashui Wang, and Yang Liu. APICraft: Fuzz driver generation for closed-source SDK libraries. In30th USENIX Security Symposium (USENIX Security 21), pages 2811–2828, 2021

    2021

  20. [28]

    Automatic library fuzzing through api relation evolvement

    Jiayi Lin, Qingyu Zhang, Junzhe Li, Chenxin Sun, Hao Zhou, Changhua Luo, and Chenxiong Qian. Automatic library fuzzing through api relation evolvement. In 2025 Network and Distributed System Security Symposium (NDSS 2025), 2025

    2025

  21. [29]

    https://llvm.org/docs/LibFuzzer.html, Accessed: Jan 2026

    libfuzzer. https://llvm.org/docs/LibFuzzer.html, Accessed: Jan 2026

    2026

  22. [30]

    Libafl libfuzzer: Libfuzzer on top of libafl

    Addison Crump, Andrea Fioraldi, Dominik Maier, and Dongjia Zhang. Libafl libfuzzer: Libfuzzer on top of libafl. In2023 IEEE/ACM International Workshop on Search-Based and Fuzz Testing (SBFT), pages 70–72. IEEE, 2023

    2023

  23. [31]

    Cupid: Automatic fuzzer selection for collaborative fuzzing

    Emre Güler, Philipp Görz, Elia Geretto, Andrea Jemmett, Sebastian Österlund, Herbert Bos, Cristiano Giuffrida, and Thorsten Holz. Cupid: Automatic fuzzer selection for collaborative fuzzing. In36th Annual Computer Security Applications Conference, pages 360–372, 2020

    2020

  24. [32]

    Libafl qemu: A library for fuzzing-oriented emulation

    Romain Malmain, Andrea Fioraldi, and Aurélien Francillon. Libafl qemu: A library for fuzzing-oriented emulation. InBAR 2024, Workshop on Binary Analysis Research, colocated with NDSS 2024, 2024

    2024

  25. [33]

    Liberating libraries through automated fuzz driver generation: Striking a balance without consumer code

    Flavio Toffalini, Nicolas Badoux, Zurab Tsinadze, and Mathias Payer. Liberating libraries through automated fuzz driver generation: Striking a balance without consumer code. volume 2, New York, NY, USA, June 2025. Association for Computing Machinery

    2025

  26. [34]

    Futag: Automated fuzz target genera- tor for testing software libraries

    Chi Thien Tran and Shamil Kurmangaleev. Futag: Automated fuzz target genera- tor for testing software libraries. In2021 Ivannikov Memorial Workshop (IVMEM), pages 80–85. IEEE, 2021

    2021

  27. [35]

    Utopia: Automatic generation of fuzz driver using unit tests

    Bokdeuk Jeong, Joonun Jang, Hayoon Yi, Jiin Moon, Junsik Kim, Intae Jeon, Taesoo Kim, WooChul Shim, and Yong Ho Hwang. Utopia: Automatic generation of fuzz driver using unit tests. In2023 IEEE Symposium on Security and Privacy (SP), pages 2676–2692. IEEE, 2023

    2023

  28. [36]

    Wildsync: Automated fuzzing harness synthesis via wild api usage recovery

    Wei-Cheng Wu, Stefan Nagy, and Christophe Hauser. Wildsync: Automated fuzzing harness synthesis via wild api usage recovery. volume 2, New York, NY, USA, June 2025. Association for Computing Machinery

    2025

  29. [37]

    Hercules droidot and the murder on the jni express

    Luca Di Bartolomeo, Philipp Mao, Yu-Jye Tung, Jessy Ayala, Samuele Doria, Paolo Celada, Marcel Busch, Joshua Garcia, Eleonora Losiouk, and Mathias Payer. Hercules droidot and the murder on the jni express. In34th USENIX Conference on Security Symposium, SEC ’25, USA, 2025. USE...

    2025

  30. [38]

    Large language models are edge-case generators: Crafting unusual programs for fuzzing deep learning libraries

    Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shujing Yang, and Lingming Zhang. Large language models are edge-case generators: Crafting unusual programs for fuzzing deep learning libraries. In46th Interna- tional Conference on Software Engineering, ICSE...

    2024

  31. [39]

    Fuzz4all: Universal fuzzing with large language models

    Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Ling- ming Zhang. Fuzz4all: Universal fuzzing with large language models. In46th International Conference on Software Engineering, pages 1–13, 2024

    2024

  32. [40]

    Whitefox: White-box compiler fuzzing empowered by large language models.Proceedings of the ACM on Programming Languages, 8(OOPSLA2):709–735, 2024

    Chenyuan Yang, Yinlin Deng, Runyu Lu, Jiayi Yao, Jiawei Liu, Reyhaneh Jabbar- vand, and Lingming Zhang. Whitefox: White-box compiler fuzzing empowered by large language models.Proceedings of the ACM on Programming Languages, 8(OOPSLA2):709–735, 2024

    2024

  33. [41]

    Gpt-4 technical report.arXiv preprint arXiv:2303.08774, 2023

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Floren- cia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report.arXiv preprint arXiv:2303.08774, 2023

    2023 arXiv

  34. [42]

    Starcoder: May the source be with you!Transactions on machine learning research, 2023

    R Li, LB Allal, Y Zi, N Muennighoff, D Kocetkov, C Mou, M Marone, C Akiki, J Li, J Chim, et al. Starcoder: May the source be with you!Transactions on machine learning research, 2023

    2023

  35. [43]

    Testing the limits: Unusual text inputs generation for mobile app crash detection with large language model

    Zhe Liu, Chunyang Chen, Junjie Wang, Mengzhuo Chen, Boyu Wu, Zhilin Tian, Yuekai Huang, Jun Hu, and Qing Wang. Testing the limits: Unusual text inputs generation for mobile app crash detection with large language model. In46th International Conference on Software Engineering, ...

    2024

  36. [44]

    Elfuzz: efficient input generation via llm-driven synthesis over fuzzer space

    Chuyang Chen, Brendan Dolan-Gavitt, and Zhiqiang Lin. Elfuzz: efficient input generation via llm-driven synthesis over fuzzer space. In34th USENIX Conference on Security Symposium, USA, 2025. USENIX Association

    2025

  37. [45]

    Error messages to fuzzing: Detecting xps parsing vulnerabilities in windows printing components

    Yunpeng Tian, Feng Dong, Junhai Wang, Mu Zhang, Zhiniang Peng, Zesen Ye, Xiapu Luo, and Haoyu Wang. Error messages to fuzzing: Detecting xps parsing vulnerabilities in windows printing components. In2025 ACM SIGSAC Conference on Computer and Communications Security, CCS ’25, p...

    2025

  38. [46]

    Yuancheng Jiang, Chuqi Zhang, Bonan Ruan, Jiahao Liu, Manuel Rigger, Roland H. C. Yap, and Zhenkai Liang. Fuzzing the php interpreter via dataflow fusion. In34th USENIX Conference on Security Symposium, SEC ’25, USA, 2025. USENIX Association

    2025

  39. [47]

    Aimfuzz: Automated function- level in-memory fuzzing on binaries

    Taewook Kim, Seokhyun Hong, and Yeongpil Cho. Aimfuzz: Automated function- level in-memory fuzzing on binaries. In19th ACM Asia Conference on Computer and Communications Security, ASIA CCS ’24, page 1510–1522, New York, NY, USA, 2024. Association for Computing Machinery

    2024

  40. [48]

    Is the following {parameter_name} a function pa- rameter by reference? The answer is output in json format. Below is a sample output: {

    Gabriel Sherman and Stefan Nagy. No harness, no problem: Oracle-guided harnessing for auto-generating c api fuzzing harnesses. In2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), pages 775–775. IEEE Computer Society, 2025. Open Science To ensure trans...

    2025

Pith tools

Reviewed July 9, 2026 · model on record in the stance chip above.