CrashFixer: A crash resolution agent for the Linux kernel

TL;DR

CrashFixer introduces an execution-aware, two-phase approach to automatically repair Linux kernel crashes discovered via fuzzing, aligning with developer workflows through Hypothesis Generation and Patch Generation, and scales evaluation with the enhanced kGymSuite platform. By collecting minimal yet informative execution traces and enabling fast patch validation via SuiteCache, CrashFixer achieves substantial crash-resolution rates across the kBenchSyz benchmark and open Syzkaller bugs, with patches categorized as plausible, helpful, or incorrect. The work highlights the potential of autonomously accelerating kernel patch velocity and reliability, while also exposing challenges around preserving semantic behavior and ensuring patch correctness without extensive unit-test infrastructure. Collectively, CrashFixer and kGymSuite offer a practical, open research platform to advance large-system repair in the kernel and beyond, pointing to future directions in trust, validation, and semantics-preserving fixes.

Abstract

Code large language models (LLMs) have shown impressive capabilities on a multitude of software engineering tasks. In particular, they have demonstrated remarkable utility in the task of code repair. However, common benchmarks used to evaluate the performance of code LLMs are often limited to small-scale settings. In this work, we build upon kGym, which shares a benchmark for system-level Linux kernel bugs and a platform to run experiments on the Linux kernel. This paper introduces CrashFixer, the first LLM-based software repair agent that is applicable to Linux kernel bugs. Inspired by the typical workflow of a kernel developer, we identify the key capabilities an expert developer leverages to resolve a kernel crash. Using this as our guide, we revisit the kGym platform and identify key system improvements needed to practically run LLM-based agents at the scale of the Linux kernel (50K files and 20M lines of code). We implement these changes by extending kGym to create an improved platform - called kGymSuite, which will be open-sourced. Finally, the paper presents an evaluation of various repair strategies for such complex kernel bugs and showcases the value of explicitly generating a hypothesis before attempting to fix bugs in complex systems such as the Linux kernel. We also evaluated CrashFixer's capabilities on still open bugs, and found at least two patch suggestions considered plausible to resolve the reported bug.

Figures (9)

• Figure 1: The crash-fixing workflow of a kernel developer. CrashFixer follows this flow to generate hypothesis and patch.
• Figure 2: CrashFixer Pipeline.
• Figure 3: Iterative Debug Cycle represented with a tree or forest. Each node $N_i$ represents a debug cycle and is associated with a state $(C_{i-1}, R_{i-1})$—the codebase and resulting crash report. The tree is parameterized by maximum depth $\mathcal{D}$ and branching factor $\mathcal{B}$. The root node $N_1$ starts from $(C_0, R_0)$, the initial codebase and crash report.
• Figure 4: The trace-minimization algorithm starts by scanning the execution trace backward to find all stack-trace functions (green) from the localized file in order, ignoring untraced ones (blue). This matching region, labeled “match,” may also include additional relevant functions like q and repeated calls like m. We refer to this first step as "stack trace anchoring". Then, the span is expanded backwards and forwards until a repeating pattern of trace functions is detected (q, q, ... in the prefix, and p, m, p, m in the suffix), up to a maximum number of function records.
• Figure 5: Hypothesis for UBSAN bug.