Crash Report Accumulation During Continuous Fuzzing

TL;DR

The paper tackles the challenge of handling the flood of crashes produced by continuous fuzzing by introducing a crash-accumulation method that preserves previously established crash clusters while integrating new results. The approach combines trace grouping (Dup, Inner, Outer, Oot), strong-condition updates, and hierarchical clustering, with multiple variants (Hard, Soft, Combined, Hierarchical) implemented in the CASR-Cluster tool. Key findings show improved silhouette scores over reclustering in many targets, and a capacity to avoid degrading the existing cluster structure, thereby aiding efficient crash triage in secure software development workflows. The method has practical impact for tracking regressions and new errors across software releases while reducing redundant analysis and maintaining consistency across fuzzing cycles on Linux systems.

Abstract

Crash report accumulation is a necessary step during continuous fuzzing. Dynamic software analysis techniques like fuzzing and dynamic symbolic execution generate a large number of crashes for analysis. However, the time and resource constraints often lead to the postponement of fixing some less critical issues, potentially introducing new errors in future releases. Thus, there is a need to distinguish new errors from old ones. We propose a crash accumulation method and implemented it as part of the CASR toolset. We evaluated our approach on crash reports collected from fuzzing results.

Figures (11)

• Figure 1: Standard crash analysis scenario scheme
• Figure 2: Hierarchical clustering dendrogram
• Figure 3: Reclustering and mapping example
• Figure 4: Bad reclustering example
• Figure 5: Minimum diameter example