Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

Fixing 7,400 Bugs for 1$: Cheap Crash-Site Program Repair

T0 review · 4 major / 4 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read WILLIAM T claims that repairing at the crash site—inserting a one-line guard before the crashing access rather than locating and fixing the root cause—is a much cheaper alternative to agentic root-cause repair for memory-corruption bugs…

desk verdict The cost story is real and the crash-site repair idea is worth discussing, but the headline fix-rate claims rest on a plausible-patch metric that the authors themselves show to be far too permissive, so the central comparison to CodeRover-S is not supported as stated. read the letter →

arxiv 2505.13103 v2 pith:SY7GFFTZ submitted 2025-05-19 cs.SE cs.CR

Han Zheng , Ilia Shumailov , Tianqi Fan , Aiden Hall , Mathias Payer This is my paper · ORCID
classification cs.SEcs.CR
keywords crash-siterepairautomatedprogramlargelanguagemodelsmemorycorruptiontemplate-guidedpatchgenerationsanitizerreportsARVObenchmarkplausible
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

WILLIAM T claims that repairing at the crash site—inserting a one-line guard before the crashing access rather than locating and fixing the root cause—is a viable, much cheaper alternative to agentic root-cause repair. The paper builds templates for four common sanitizer bug classes and uses regex parsing of AddressSanitizer reports so the LLM only names a few key variables. On the ARVO benchmark it reports a 46.1% plausible fix rate with GPT-4o at about $0.0026 per bug, and when run before the CodeRover-S agent the combined pipeline fixes 73.5% of bugs while cutting token cost by 45.9%. The practical point is that fuzzer report backlogs could be triaged and contained with local, low-cost models instead of frontier LLM agents.

What carries the argument

The load-bearing mechanism is template-guided patch generation constrained to crash sites. WILLIAM T recognizes which of four ASan categories the bug belongs to and chooses one of two safety-check templates: stop_spatial(buf, buf_size, ptr), which exits if ptr falls outside buf through buf+buf_size, and stop_temporal(ptr), which exits if the pointer has been freed. Regex-based context retrieval supplies the crash frame and a two-line code window, so the LLM's entire output is JSON containing the needed variable names. This reduces token use and model capability requirements while keeping patches behavior-preserving when no early exit occurs.

What would settle it

Run each of the 165 plausible WILLIAM T patches against the project's existing test suite or a corpus of non-PoC inputs and record early exits and behavioral differences; if most guards fire on valid inputs, the plausible rate is not a true fixing rate. Appendix A already reports 70 early-exit and 39 blocked-valid-input cases among those 165, so the calculation is directly available.

Watch

Extended reading notes

Core claim

The central claim is that crash-site repair can reach near-state-of-the-art plausible fixing without root-cause analysis. WILLIAM T reproduces the proof-of-concept in a Docker image, parses the sanitizer output with regular expressions to locate the crash, and prompts an LLM only to identify the buffer, its size, and the offending pointer (or, for use-after-free, the freed pointer). A one-line call to stop_spatial or stop_temporal is inserted immediately above the crash site; these guards call exit(0) when the dangerous access is detected. Evaluated on 358 reproducible ARVO memory-corruption bugs, WILLIAM T with GPT-4o produces 165 plausible patches (46.1%), while CodeRover-S alone produces 195 (54.5%). Because the two systems fix mostly disjoint bugs, running WILLIAM T first and CodeRover-S second yields 73.5% plausible fixes, a 29.6-point increase, while reducing token consumption by 45.9% relative to CodeRover-S alone. Template guidance also removes the need for reasoning models: the non-reasoning Claude-3.5-Haiku has the highest single-system rate (47.5%), and a 27B Gemma model running locally reaches about 96.4% of the GPT-4o rate.

Load-bearing premise

All headline rates count a patch as fixed if the patched program no longer crashes on the given proof-of-concept input, even when the guard merely exits the program before the vulnerable code runs.

Editorial extensions

If this is right

  • A fuzzing team with a fixed monthly LLM budget can process orders of magnitude more reports: the paper reports 357 times more bugs fixed per dollar than CodeRover-S on the same backend model.
  • Because the fixed sets are largely disjoint, the recommended deployment is a two-stage pipeline: WILLIAM T first (cheap), CodeRover-S or a similar agent second, giving +29.6% plausible fixes at 45.9% lower token cost.
  • No frontier reasoning model is needed; a 27B locally hosted model on consumer hardware retains about 96.4% of the GPT-4o fixing rate, making on-premise repair plausible.
  • Wall-clock cost drops from about 43.5 minutes per bug for CodeRover-S to under 3 minutes for WILLIAM T, including compilation, which makes per-report triage feasible.

Reading between the lines

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

  • If fixes are judged by whether the program keeps executing on the PoC instead of just not crashing, WILLIAM T's 165 plausible patches shrink to 95, and manual review over a broader input set leaves 56; the same strictness would lower the combined 73.5% figure, so all reported rates should be read as plausible-patch upper bounds.
  • The guard-insertion strategy should transfer to other sanitizer fault classes and to non-exit responses such as returning error codes, though the paper does not test those extensions.
  • Deploying crash-site guards at scale would accumulate deliberate early-exit call sites that still need eventual root-cause fixes; a tracking layer that marks guard-inserted exits for follow-up would convert one-shot containment into a sustainable repair workflow.
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

4 major / 4 minor

Summary. The paper presents WILLIAM T, an automated program repair (APR) agent for memory-corruption bugs found by fuzzing. It uses regex-based parsing of AddressSanitizer reports to locate the crash site, asks an LLM only to identify key variables, and inserts one of two predefined guard templates just before the crash site. The evaluation is on 358 reproducible ARVO bugs and compares WILLIAM T with AutoCodeRover-S, Agentless, and VulMaster. The headline results are a plausible fix rate of 46.1% for WILLIAM T-GPT-4o, a token-cost reduction of 99.7% versus CodeRover-S, and a combined WILLIAM T + CodeRover-S pipeline that reportedly fixes 73.5% of bugs at 45.9% lower token cost. The paper also tests Gemma local models and claims practical deployment on a Mac Mini M4.

Significance. The cost architecture is a genuine strength: the one-shot design and template-constrained LLM use are measured with concrete dollar, token, and time figures, the ARVO benchmark is external and reproducible, and the finding that WILLIAM T and CodeRover-S fix largely disjoint bug sets is interesting even under the plausible metric. If the stricter validation in Appendix A were applied to all baselines and the headline numbers revised accordingly, the paper would still make a useful contribution as a cheap crash-suppression or pre-repair triage tool. In its current form, however, the central 'bug-fixing rate' claims are not supported by the evidence the authors themselves present.

major comments (4)
  1. [Abstract; §5 'Repair Metrics'; Appendix A, Fig. 9] All headline fix rates (46.1%, 73.5%, +29.6%) are 'Plausible' rates, defined in §5 as only 'patched program does not crash when taking the PoC as input.' Appendix A shows that this metric is not a correctness measure: of WILLIAM T-GPT-4o's 165 plausible patches, only 95 avoid an early exit on the PoC and only 56 pass manual review on broader inputs, reducing WILLIAM T's verified fix rate from 46.1% (165/358) to 15.6% (56/358). Because the abstract and RQ summaries present the plausible rates without this caveat, the paper's central claim that WILLIAM T 'fixes' bugs at near-SoTA rates and that the combined pipeline 'increases the bug-fixing rate to 73.5%' is not supported as stated. These numbers need to be either corrected to verified rates or explicitly relabeled as crash-suppression rates, with corresponding changes in the abstract, RQ answers, and conclusion.
  2. [Appendix A] The validation is asymmetric in a way that affects the comparison. The authors state that they do not perform the early-exit/manual verification for CodeRover-S or the other SoTA agents. Since the claimed advantage of the combined pipeline (+29.6% fixing rate) is computed from plausible rates, it could be an artifact of WILLIAM T's templates being designed to exit(0) on the detected condition while the baselines may attempt more substantive edits. The revision should either apply the same two-stage validation to the baseline patches or provide a sensitivity analysis (for example, applying the WILLIAM T early-exit ratio to the baselines) before claiming a fix-rate improvement.
  3. [§3, §4, Appendix B] The repair templates are crash-suppression guards: stop_spatial and stop_temporal call exit(0) when the identified access is out of bounds or the pointer is destroyed. Such a patch is counted as 'Plausible' because the PoC no longer reaches the sanitizer failure, but it does not repair the underlying bug and, as Fig. 9 shows, 70 of 165 plausible WILLIAM T patches introduce early exits even on the PoC. This makes the title's 'Fixing 7,400 Bugs for 1$' and the framing of crash-site repair as 'mitigating the risk of exploitation' rather than fixing require consistent terminology: the system is better described as automated crash suppression or triage, and the 'fixing rate' claims should be scoped accordingly.
  4. [Abstract and §5.2] There is also a numerical inconsistency in the headline pipeline claim: §5.2 says the pipeline achieves 60 additional plausible fixes on top of CodeRover-S's 195, which is 255/358 = 71.2%, not the 73.5% stated in the Abstract. The stated '+29.6% improvement' also does not match the given counts: 60 additional fixes out of 195 is a 30.8% relative increase. Because these numbers are load-bearing for the abstract, they must be reconciled and recalculated from a clearly specified denominator.
minor comments (4)
  1. [§5.2 and §5.3] The research question numbering is swapped: the evaluation plan lists RQ2 as scaling to smaller LLMs, but §5.2 is titled 'RQ2: What kind of bugs...' and §5.3 answers the scaling question as RQ3. Renumber or reorder the sections to match the stated RQs.
  2. [§7 Conclusion] The conclusion states 'reduces token usage by 29.6% and improves the fixing rate by 45.9%', which reverses the abstract's 45.9% cost reduction and 29.6% fix-rate improvement. Correct this inconsistency.
  3. [§5.1 and Figure 5c] The text in §5.1 says VulMaster resolves 5 bugs in total, while the caption of Figure 5c says VulMaster failed to generate any plausible patches. Reconcile these conflicting statements and ensure the figure and text describe the same result.
  4. [Appendix A, Figure 9] The figure's top-level branch '165 Plausible Patch' followed by '48 Patch Compiled' is confusing because a plausible patch by definition compiles; clarify whether the counts below '165' are for all 358 bugs or for the 165 plausible patches, and add clear labels to the branches.

Circularity Check

1 steps flagged · score 6.0 of 10

Headline '73.5% bug-fixing rate' is a plausible-patch count whose main component is constructed to satisfy it: WILLIAM T's templates insert exit(0) before the crash, so any correct variable identification makes the PoC 'not crash' by definition; Appendix A's stricter review leaves only 56/165 true fixes.

  1. self definitional [Abstract / Sec. 5 'Repair Metrics' / Appendix B 'The Vulnerability Fixing Template' (Figs. 12-13)]
    "Plausible: patched program does not crash when taking the PoC as input. We consider the plausible rate as the successful fixing rate to align with other SoTAs [60]. ... void stop_spatial(void *buf, size_t buf_size, void *ptr) { if (ptr >= buffer + buf_size || ptr < buf) { exit(0); } }"

    Under the paper's metric, a WILLIAM T patch is 'Plausible' iff the PoC no longer crashes. The spatial/temporal templates are guards that call exit(0) as soon as the crash condition (out-of-bounds pointer or freed pointer) is true. Therefore every WILLIAM T patch that compiles and has the LLM correctly identify the buffer/pointer is automatically 'Plausible': the program exits before the ASan crash. The reported 'bug-fixing rate' of 46.1% thus measures crash-site variable identification, not bug repair. The paper's Appendix A confirms that only 56/165 plausible WILLIAM T patches survive manual correctness review, and the same stricter check was not run on CodeRover-S, leaving the +29.6% improvement claim unsubstantiated as a fix-rate comparison.

full rationale

The cost and scalability claims are independent and externally benchmarked: the 99.7% token reduction, $0.0026-per-bug cost, and local-model results do not reduce to the repair metric. The central 'bug-fixing rate' claim, however, is partially circular: the success metric is defined as 'PoC no longer crashes,' and WILLIAM T's templates are designed to call exit(0) on exactly the crash condition, so a successful patch satisfies the metric by construction whenever variable identification succeeds and the patch compiles. The paper discloses the fragility of the plausible metric in Sec. 6 and Appendix A, and even reports that only 56/165 WILLIAM T plausible patches are correct under manual review, but the abstract, RQ summaries, and conclusion still present the inflated plausible counts without this caveat. Moreover, Appendix A states that the stricter validation was not performed on CodeRover-S or other baselines, making the claimed +29.6% improvement over CodeRover-S a comparison of unfiltered plausible rates rather than verified fixes. No load-bearing self-citation chain or uniqueness theorem is present; the circularity is in the equivalence between the template's exit(0) behavior and the metric's success condition. Score 6 reflects that one central 'prediction' reduces by construction, while the cost and scalability findings retain independent content.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claims rest on the plausible-fix metric, the ARVO subset selection, and hand-designed templates whose primary action is exit(0). No theory-level free parameters are present; the free parameters listed are engineering choices that shape every reported number.

free parameters (3)
  • ARVO compile-time selection threshold = 15 minutes
    Hand-chosen cutoff selecting 358 of >5,000 ARVO bugs; all reported fix rates and costs are conditional on this subset.
  • Patch template behavior (exit(0) on detected condition)
    Design choice that guarantees 'not crashing on PoC' for any correctly identified bug, inflating the plausible rate; central to the headline results.
  • Crash-site context window = 2 lines before/after
    Regex retrieval extracts a 2-line window around the crash; variables outside this window cannot be identified by the LLM, directly affecting the fix rate.
assumptions (4)
  • domain assumption AddressSanitizer reports are well-formed and the regex parser reliably identifies bug type, user crash frame, and source lines.
    Invoked in Appendix C; if parsing fails, no patch is generated.
  • domain assumption A guard immediately before the crash site mitigates exploitation risk, following Chrome's CHECK recommendation [8].
    Sec 3; the entire crash-site repair paradigm rests on this, but no exploit-level validation is performed.
  • domain assumption The template helper functions (malloc_usable_size for heap size, is_destroyed for freed pointers) are correct in all target projects.
    Appendix B; for example, malloc_usable_size may not exist or may return a usable size not equal to the requested size on all allocators.
  • domain assumption The imported SoTA results (CodeRover-S [60], Agentless [54], VulMaster [64]) are accurate and were measured under comparable conditions.
    Sec 5.1, where the paper states 'Because AutoCodeRover-S is not open-source, we import the fixes provided by AutoCodeRover-S for all three SoTAs.'

how reviews work

0 comments
Cite this review

Pith. "Pith review of Fixing 7,400 Bugs for 1$: Cheap Crash-Site Program Repair." pith.science (2026). https://pith.science/paper/SY7GFFTZ

@misc{pith2026250513103,
  author       = {Pith},
  title        = {Pith review of: Fixing 7,400 Bugs for 1$: Cheap Crash-Site Program Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SY7GFFTZ}},
  note         = {Machine review of arXiv:2505.13103}
}
read the original abstract

The rapid advancement of bug-finding techniques has led to the discovery of more vulnerabilities than developers can reasonably fix, creating an urgent need for effective Automated Program Repair (APR) methods. However, the complexity of modern bugs often makes precise root cause analysis difficult and unreliable. To address this challenge, we propose crash-site repair to simplify the repair task while still mitigating the risk of exploitation. In addition, we introduce a template-guided patch generation approach that significantly reduces the token cost of Large Language Models (LLMs) while maintaining both efficiency and effectiveness. We implement our prototype system, WILLIAMT, and evaluate it against state-of-the-art APR tools. Our results show that, when combined with the top-performing agent CodeRover-S, WILLIAMT reduces token cost by 45.9% and increases the bug-fixing rate to 73.5% (+29.6%) on ARVO, a ground-truth open source software vulnerabilities benchmark. Furthermore, we demonstrate that WILLIAMT can function effectively even without access to frontier LLMs: even a local model running on a Mac M4 Mini achieves a reasonable repair rate. These findings highlight the broad applicability and scalability of WILLIAMT.

Figures

Figures reproduced from arXiv: 2505.13103 by the authors.

Figure 1
Figure 1. Workflow of Current LLM-based Program Repairing Agents vs [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Example Memory Corruption Vulnerabilties. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Root Cause and Crash Site of Bug 66992. reconstructs and curates a reproducible dataset of OSS bugs specifically tailored for APR evaluation. Compared to other ground-truth memory corruption datasets [14, 10, 2], ARVO automates the entire compilation pipeline and ensures reproducibility. This automation facilitates fair and consistent comparisons across different APR tools. 3 Primer on Bug Fixing The objective of au… view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: The fix performance of WILLIAMT (with GPT-4o) and other SoTAs [60, 64, 54]. Multiple means the CodeRover-S takes multiple attempts to find plausible fix [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 6
Figure 6. Figure 6: The WILLIAMT performance with different LLMs. ds: DeepSeek, gm: Gemma3 [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Token and Price Cost for different LLMs. ds: DeepSeek, gm: Gemma3. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 9
Figure 9. Figure 9: The actual fix ratio of WILLIAMT-GPT-4o. To better understand this gap, we analyze the patches generated by WILLIAMT-GPT-4o as an example, manually evaluating all plausible patches as shown in [PITH_FULL_IMAGE:figures/full_fig_p014_9.png]
Figure 10
Figure 10. Figure 10: Example to automating the PoC execution comparision. [PITH_FULL_IMAGE:figures/full_fig_p015_10.png]
Figure 11
Figure 11. Figure 11: Exploitable Bug Types Distribution in ARVO. We merge the bug categories less than 3% [PITH_FULL_IMAGE:figures/full_fig_p015_11.png]
Figure 12
Figure 12. Figure 12: Repairing Template For Temporal Memory Corruptions. [PITH_FULL_IMAGE:figures/full_fig_p016_12.png]
Figure 13
Figure 13. Figure 13: Repairing Template For Spatial Memory Corruptions. [PITH_FULL_IMAGE:figures/full_fig_p016_13.png]
Figure 14
Figure 14. Figure 14: AddressSanitizer Error Report for bug 20004. [PITH_FULL_IMAGE:figures/full_fig_p017_14.png]
Figure 15
Figure 15. Figure 15: LLM Prompt to analyze bug 20004. 18 [PITH_FULL_IMAGE:figures/full_fig_p018_15.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Seeing is Fixing: Cross-Modal Reasoning with Multimodal LLMs for Visual Software Issue Fixing

    cs.SE 2025-06 conditional novelty 6.0 of 10

    GUIRepair, a cross-modal LLM pipeline that converts issue screenshots into reproduction code and rendered patch screenshots into validation feedback, resolves 157/517 SWE-bench M instances with GPT-4o and 175 with o4-mini.

Reference graph

Works this paper leans on

65 extracted references · 54 canonical work pages · cited by 1 Pith paper

  1. [1]

    X AI. Grok. https://x.ai/, 2025

    work page 2025

  2. [2]

    Cvefixes: automated collection of vulner- abilities and their fixes from open-source software

    Guru Bhandari, Amara Naseer, and Leon Moonen. Cvefixes: automated collection of vulner- abilities and their fixes from open-source software. In Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering, pages 30–39, 2021

    2021

  3. [3]

    Escape modern web-based app sandbox from site- isolation perspective

    Liu Bohan and Shi Haibin. Escape modern web-based app sandbox from site- isolation perspective. https://i.blackhat.com/Asia-24/Presentations/ Asia-24-Liu-The-Hole-in-Sandbox.pdf , 2024

    work page 2024

  4. [4]

    Reviving jit vulnerabilities: Unleashing the power of maglev compiler bugs on chrome browser

    Liu Bohan and Wang Zheng. Reviving jit vulnerabilities: Unleashing the power of maglev compiler bugs on chrome browser. https://i.blackhat.com/EU-23/Presentations/ EU-23-Liu-Reviving-JIT-Vulnerabilities.pdf , 2023

    work page 2023

  5. [5]

    In 33rd USENIX Security Symposium (USENIX Security 24), pages 919–935, 2024

    Alexander Bulekov, Qiang Liu, Manuel Egele, and Mathias Payer.{HYPERPILL}: Fuzzing for hypervisor-bugs by leveraging the hardware virtualization interface. In 33rd USENIX Security Symposium (USENIX Security 24), pages 919–935, 2024

    work page 2024

  6. [6]

    Taking the next step: Oss-fuzz in 2023, 2023

    Oliver Chang and OSS-Fuzz team. Taking the next step: Oss-fuzz in 2023, 2023

    work page 2023

  7. [7]

    Sequencer: Sequence-to-sequence learning for end-to-end program repair

    Zimin Chen, Steve Kommrusch, Michele Tufano, Louis-Noël Pouchet, Denys Poshyvanyk, and Martin Monperrus. Sequencer: Sequence-to-sequence learning for end-to-end program repair. IEEE Transactions on Software Engineering, 47(9):1943–1959, 2019

    work page 1943

  8. [8]

    Top security things for chromies to remember

    chromium. Top security things for chromies to remember. https://chromium. googlesource.com/chromium/src/+/lkgr/docs/security/checklist.md, 2025

    work page 2025

Show all 65 references
  1. [9]

    Cyber grand challenge - datasets, 2025

    DARPA. Cyber grand challenge - datasets, 2025

    2025

  2. [10]

    Ac/c++ code vulnerability dataset with code changes and cve summaries

    Jiahao Fan, Yi Li, Shaohua Wang, and Tien N Nguyen. Ac/c++ code vulnerability dataset with code changes and cve summaries. In Proceedings of the 17th international conference on mining software repositories, pages 508–512, 2020

    2020

  3. [11]

    Codebert: A pre-trained model for programming and natural languages

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al. Codebert: A pre-trained model for programming and natural languages. arXiv preprint arXiv:2002.08155, 2020

    2002 arXiv

  4. [12]

    Afl++ combining incremental steps of fuzzing research

    Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. Afl++ combining incremental steps of fuzzing research. In Proceedings of the 14th USENIX Conference on Offensive Technologies, pages 10–10, 2020

    2020

  5. [13]

    {ACTOR}:{Action-Guided} kernel fuzzing

    Marius Fleischer, Dipanjan Das, Priyanka Bose, Weiheng Bai, Kangjie Lu, Mathias Payer, Christopher Kruegel, and Giovanni Vigna. {ACTOR}:{Action-Guided} kernel fuzzing. In 32nd USENIX Security Symposium (USENIX Security 23), pages 5003–5020, 2023

    2023

  6. [14]

    Beyond tests: Program vulnerability repair via crash constraint extraction

    Xiang Gao, Bo Wang, Gregory J Duck, Ruyi Ji, Yingfei Xiong, and Abhik Roychoudhury. Beyond tests: Program vulnerability repair via crash constraint extraction. ACM Transactions on Software Engineering and Methodology (TOSEM), 30(2):1–27, 2021. 10

    2021

  7. [15]

    Clusterfuzz

    google. Clusterfuzz. https://google.github.io/clusterfuzz/, 2023

    2023

  8. [16]

    Oss-fuzz - continuous fuzzing for open source software, 2025

    Google. Oss-fuzz - continuous fuzzing for open source software, 2025

    2025

  9. [17]

    syzkaller is an unsupervised coverage-guided kernel fuzzer

    Google. syzkaller is an unsupervised coverage-guided kernel fuzzer. https://github.com/ google/syzkaller, 2025

    2025

  10. [18]

    Welcome gemma 3: Google’s all new multimodal, multilingual, long context open llm

    Google. Welcome gemma 3: Google’s all new multimodal, multilingual, long context open llm. http://huggingface.co/blog/gemma3, 2025

    2025

  11. [19]

    Fuzzilli: Fuzzing for javascript jit compiler vulnerabilities

    Samuel Groß, Simon Koch, Lukas Bernhard, Thorsten Holz, and Martin Johns. Fuzzilli: Fuzzing for javascript jit compiler vulnerabilities. In NDSS, 2023

    2023

  12. [20]

    Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning

    Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang, Xiao Bi, et al. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning. arXiv preprint arXiv:2501.12948, 2025

    2025 arXiv

  13. [21]

    An empirical study on fine-tuning large language models of code for automated program repair

    Kai Huang, Xiangxin Meng, Jian Zhang, Yang Liu, Wenjie Wang, Shuhao Li, and Yuqing Zhang. An empirical study on fine-tuning large language models of code for automated program repair. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages...

    2023

  14. [22]

    Template-guided program repair in the era of large language models

    Kai Huang, Jian Zhang, Xiangxin Meng, and Yang Liu. Template-guided program repair in the era of large language models. ICSE, 2025

    2025

  15. [23]

    Another way to talk with browser : Exploiting chrome at net- work layer

    Rong Jian and Guang Gong. Another way to talk with browser : Exploiting chrome at net- work layer. https://i.blackhat.com/USA-22/Thursday/US-22-Rong-Another_Way_ to_Talk_with_Browser_Exploiting_Chrome_at_Network_Layer.pdf, 2022

    2022

  16. [24]

    Recommendations from the workshop on open-source software security ini- tiative

    Angelos Keromytis. Recommendations from the workshop on open-source software security ini- tiative. https://bpb-us-e1.wpmucdn.com/sites.gatech.edu/dist/a/2878/files/ 2022/10/OSSI-Final-Report.pdf , 2022

    2022

  17. [25]

    libfuzzer

    libfuzzer. libfuzzer. https://llvm.org/docs/LibFuzzer.html, 2023

    2023

  18. [26]

    Deepseek-v3 technical report

    Aixin Liu, Bei Feng, Bing Xue, Bingxuan Wang, Bochao Wu, Chengda Lu, Chenggang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ruan, et al. Deepseek-v3 technical report. arXiv preprint arXiv:2412.19437, 2024

    2024 arXiv

  19. [27]

    Videzzo: Dependency-aware virtual device fuzzing

    Qiang Liu, Flavio Toffalini, Yajin Zhou, and Mathias Payer. Videzzo: Dependency-aware virtual device fuzzing. In 2023 IEEE Symposium on security and privacy (SP) , pages 3228–3245. IEEE, 2023

    2023

  20. [28]

    Truman: Constructing device behavior models from os drivers to fuzz virtual devices

    Zheyu Ma, Qiang Liu, Zheming Li, Tingting Yin, Wende Tan, Chao Zhang, and Mathias Payer. Truman: Constructing device behavior models from os drivers to fuzz virtual devices

  21. [29]

    Achieving linux kernel code execution through a malicious usb device

    Bogaard Martijn and Geist Dana. Achieving linux kernel code execution through a malicious usb device. https://i.blackhat.com/EU-21/Thursday/EU-21-Bogaard_Geist_ Achieving_Linux_Kernel_Code_Execution_Through_A_Malicious_USB_Device. pdf, 2021

    2021

  22. [30]

    Arvo: Atlas of reproducible vulnerabilities for open source software

    Xiang Mei, Pulkit Singh Singaria, Jordi Del Castillo, Haoran Xi, Tiffany Bao, Ruoyu Wang, Yan Shoshitaishvili, Adam Doupé, Hammond Pearce, Brendan Dolan-Gavitt, et al. Arvo: Atlas of reproducible vulnerabilities for open source software. arXiv preprint arXiv:2408.02153, 2024

    2024 arXiv

  23. [31]

    The llama 4 herd: The beginning of a new era of natively multimodal ai innovation

    Meta. The llama 4 herd: The beginning of a new era of natively multimodal ai innovation. https://ai.meta.com/blog/llama-4-multimodal-intelligence/ , 2025

    2025

  24. [32]

    Exploit chrome and firefox four times

    Wang Nan and Xiao Zhenghang. Exploit chrome and firefox four times. https://i.blackhat.com/BH-US-24/Presentations/ US24-Xiao-Super-Hat-Trick-Exploit-Chrome-and-Firefox.pdf , 2024

    2024

  25. [33]

    Hacking the stack for fun and profit

    Aleph One. Hacking the stack for fun and profit. Phrack Magazine, 1996. 11

    1996

  26. [34]

    OpenAI. Chatgpt. https://chatgpt.com, 2025

    2025

  27. [35]

    V-shuttle: Scalable and semantics-aware hypervisor virtual device fuzzing

    Gaoning Pan, Xingwei Lin, Xuhong Zhang, Yongkang Jia, Shouling Ji, Chunming Wu, Xinlei Ying, Jiashui Wang, and Yanjun Wu. V-shuttle: Scalable and semantics-aware hypervisor virtual device fuzzing. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications ...

    2021

  28. [36]

    Software Security: Principles, Policies, and Protection

    Mathias Payer. Software Security: Principles, Policies, and Protection. HexHive Books, 0.37 edition, July 2021

    2021

  29. [37]

    Addresssanitizercallstack, 2015

    Alexander Potapenko. Addresssanitizercallstack, 2015

    2015

  30. [38]

    Security: heap-buffer-overflow in libavif when decode the crafted avif file, 2024

    External reporter. Security: heap-buffer-overflow in libavif when decode the crafted avif file, 2024

    2024

  31. [39]

    ios 16.1.1 and ipados 16.1.1, 2024

    Apple Security. ios 16.1.1 and ipados 16.1.1, 2024

    2024

  32. [40]

    {AddressSanitizer}: A fast address sanity checker

    Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. {AddressSanitizer}: A fast address sanity checker. In2012 USENIX annual technical conference (USENIX ATC 12), pages 309–318, 2012

    2012

  33. [41]

    Breaking the chrome sandbox with mojo

    Röttger Stephen. Breaking the chrome sandbox with mojo. https://i.blackhat.com/ USA-22/Wednesday/US-22-Roettger_Breaking_the_Chrome_Sandbox_with_Mojo. pdf, 2022

    2022

  34. [42]

    Memory safe languages in android 13, 2022

    Jeffrey Vander Stoep. Memory safe languages in android 13, 2022

    2022

  35. [43]

    The more you know, the more you know you don’t know - a year in review of 0-days used in-the-wild in 2021, 2022

    Maddie Stone. The more you know, the more you know you don’t know - a year in review of 0-days used in-the-wild in 2021, 2022

    2021

  36. [44]

    Syzbot open bugs, 2025

    Syzbot. Syzbot open bugs, 2025

    2025

  37. [45]

    Code repair with llms gives an exploration-exploitation tradeoff.Advances in Neural Information Processing Systems, 37:117954–117996, 2024

    Hao Tang, Keya Hu, Jin Zhou, Si Cheng Zhong, Wei-Long Zheng, Xujie Si, and Kevin Ellis. Code repair with llms gives an exploration-exploitation tradeoff.Advances in Neural Information Processing Systems, 37:117954–117996, 2024

    2024

  38. [46]

    Memory safety in chromium, 2025

    Chromium Security Team. Memory safety in chromium, 2025

    2025

  39. [47]

    Gemma: Open models based on gemini research and technology

    Gemma Team, Thomas Mesnard, Cassidy Hardin, Robert Dadashi, Surya Bhupatiraju, Shreya Pathak, Laurent Sifre, Morgane Rivière, Mihir Sanjay Kale, Juliette Love, et al. Gemma: Open models based on gemini research and technology. arXiv preprint arXiv:2403.08295, 2024

    2024 arXiv

  40. [48]

    Qwq-32b: Embracing the power of reinforcement learning, March 2025

    Qwen Team. Qwq-32b: Embracing the power of reinforcement learning, March 2025

    2025

  41. [49]

    An empirical study on learning bug-fixing patches in the wild via neural machine translation

    Michele Tufano, Cody Watson, Gabriele Bavota, Massimiliano Di Penta, Martin White, and Denys Poshyvanyk. An empirical study on learning bug-fixing patches in the wild via neural machine translation. ACM Transactions on Software Engineering and Methodology (TOSEM), 28(4):1–29, 2019

    2019

  42. [50]

    Dumpling: Fine-grained differential javascript engine fuzzing

    Liam Wachter, Julian Gremminger, Christian Wressnegger, Mathias Payer, and Flavio Toffalini. Dumpling: Fine-grained differential javascript engine fuzzing

  43. [51]

    Syztrust: State-aware fuzzing on trusted os designed for iot devices

    Qinying Wang, Boyu Chang, Shouling Ji, Yuan Tian, Xuhong Zhang, Binbin Zhao, Gaoning Pan, Chenyang Lyu, Mathias Payer, Wenhai Wang, et al. Syztrust: State-aware fuzzing on trusted os designed for iot devices. In 2024 IEEE Symposium on Security and Privacy (SP), pages 2310–2387...

    2024

  44. [52]

    20+ ways to bypass your macos pri- vacy mechanisms

    Reguła Wojciech and Fitzl Csaba. 20+ ways to bypass your macos pri- vacy mechanisms. https://i.blackhat.com/USA21/Wednesday-Handouts/ US-21-Regula-20-Plus-Ways-to-Bypass-Your-macOS-Privacy-Mechanisms.pdf , 2021

    2021

  45. [53]

    Less training, more repairing please: revisiting automated program repair via zero-shot learning

    Chunqiu Steven Xia and Lingming Zhang. Less training, more repairing please: revisiting automated program repair via zero-shot learning. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, page...

    2022

  46. [54]

    Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt

    Chunqiu Steven Xia and Lingming Zhang. Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 819–831, 2024

    2024

  47. [55]

    Freedom: Engineering a state-of-the-art dom fuzzer

    Wen Xu, Soyeon Park, and Taesoo Kim. Freedom: Engineering a state-of-the-art dom fuzzer. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, pages 971–986, 2020

    2020

  48. [56]

    Qwen2.5 technical report

    An Yang, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, Huan Lin, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang, Jingren Zhou, Junyang Lin, Kai Dang, Keming Lu, Keqin Bao, Kexin Yang, Le Yu, Me...

    2024 arXiv

  49. [57]

    {KextFuzz}: Fuzzing {macOS} kernel {EXTensions} on apple silicon via exploiting mit- igations

    Tingting Yin, Zicong Gao, Zhenghang Xiao, Zheyu Ma, Min Zheng, and Chao Zhang. {KextFuzz}: Fuzzing {macOS} kernel {EXTensions} on apple silicon via exploiting mit- igations. In 32nd USENIX Security Symposium (USENIX Security 23) , pages 5039–5054, 2023

    2023

  50. [58]

    american fuzzy lop

    Michal Zalewski. american fuzzy lop. https://lcamtuf.coredump.cx/afl/, 2013

    2013

  51. [59]

    Autocoderover: Au- tonomous program improvement

    Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. Autocoderover: Au- tonomous program improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, pages 1592–1604, 2024

    2024

  52. [60]

    Fixing security vulnerabilities with ai in oss-fuzz

    Yuntong Zhang, Jiawei Wang, Dominic Berzin, Martin Mirchev, Dongge Liu, Abhishek Arya, Oliver Chang, and Abhik Roychoudhury. Fixing security vulnerabilities with ai in oss-fuzz. arXiv preprint arXiv:2411.03346, 2024

    2024 arXiv

  53. [61]

    Mendelfuzz: The return of the deterministic stage

    Han Zheng, Flavio Toffalini, Marcel Böhme, and Mathias Payer. Mendelfuzz: The return of the deterministic stage. 2025

    2025

  54. [62]

    {FISHFUZZ}: Catch deeper bugs by throwing larger nets

    Han Zheng, Jiayuan Zhang, Yuhang Huang, Zezhong Ren, He Wang, Chunjie Cao, Yuqing Zhang, Flavio Toffalini, and Mathias Payer. {FISHFUZZ}: Catch deeper bugs by throwing larger nets. In 32nd USENIX Security Symposium (USENIX Security 23), pages 1343–1360, 2023

    2023

  55. [63]

    Minerva: browser api fuzzing with dynamic mod-ref analysis

    Chijin Zhou, Quan Zhang, Mingzhe Wang, Lihua Guo, Jie Liang, Zhe Liu, Mathias Payer, and Yu Jiang. Minerva: browser api fuzzing with dynamic mod-ref analysis. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Soft...

    2022

  56. [64]

    Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources

    Xin Zhou, Kisub Kim, Bowen Xu, DongGyun Han, and David Lo. Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1–13, 2024

    2024

  57. [65]

    [ SYS_INFO ] hit c ra sh sit e for % d times \ n

    Jiaxun Zhu, Minghao Lin, Tingting Yin, Zechao Cai, Yu Wang, Rui Chang, and Wenbo Shen. Crossfire: Fuzzing macos cross-xpu memory on apple silicon. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 3749–3762, 2024. A The Plausibl...

    2024

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.