This paper proposes RustGo, the new Rust-directed greybox fuzzer that effectively and fairly focuses on code regions potentially containing memory bugs and automatically identifies potential memory bug targets and accurately prunes the paths irrelevant to each target by leveraging Rust-specific static analysis.
Abstract
Rust is a popular systems programming language that provides strong memory safety and introduces low-performance overhead. While Rust guarantees memory safety through strict security policies, such as ownership, memory bugs can still occur in unsafe-related Rust codes where these policies are not fully enforced. Although such unsafe Rust code accounts for only a small portion of the entire code (e.g., 10%), existing approaches fuzz the entire code-including safe Rust, whose memory safety is already enforced by the Rust compiler-resulting in inefficient use of fuzzing resources. In this paper, we propose RustGo, the new Rust-directed greybox fuzzer that effectively and fairly focuses on code regions potentially containing memory bugs. For this, RustGo automatically identifies potential memory bug targets and accurately prunes the paths irrelevant to each target by leveraging Rust-specific static analysis. For each identified target, RustGo includes a new fuzzing approach that maintains an independent state and applies dynamic pruning to maximize balanced and focused fuzzing. We evaluate RustGo on various real-world Rust applications. On average, RustGo prunes 78.49% of irrelevant paths, reaches targets x 2.09 to x 5.08 faster than existing fuzzers, and identifies 13 unknown bugs (six assigned RUSTSEC IDs and one assigned CVE ID).
Rust guarantees memory safety without garbage collection through a strict ownership and borrowing system. However, for low-level systems programming, many widely used libraries rely on the unsafe keyword. These libraries encapsulate raw-pointer operations behind safe APIs to form safe abstractions. A single mistake in this internal unsafe code can break its safety contract, rendering the abstraction unsound and allowing safe clients to trigger undefined behavior. Detecting these potential soundness violations is challenging. Existing static analysis tools for C/C++ ignore Rust-specific safety contracts, while current Rust tools lack the deep semantic modeling required to track the contexts that raw pointers erase. To address this gap, we present UnsafeChecker, a compiler-integrated static analysis framework for detecting potential soundness violations in Rust safe abstractions. UnsafeChecker analyzes Rust MIR using a flow-sensitive abstract interpretation that maintains a shared state with three components: ownership, object validity, and layout. Each warning rule consumes the subset of facts needed for the corresponding Rust safety obligation. UnsafeChecker reports both instruction-level undefined behavior and boundary-level contract violations that may escape through safe APIs. We evaluate UnsafeChecker on a benchmark of 46 RustSec vulnerabilities, which contain 53 ground-truth bugs. UnsafeChecker outperforms several state-of-the-art tools, detecting 32 CVEs and covering 36 bugs (67.9% recall) with 51.6% alert-level precision. Furthermore, in a large-scale scan of real-world crates on crates.io, UnsafeChecker uncovered 114 previously unknown bugs across 83 crates, with 45 confirmed and 27 already fixed by maintainers.
Rust is claimed to be a type-sound language capable of preventing various undesirable behaviors, including memory bugs. However, rustc, the official Rust compiler, is not immune to defects; it contains soundness bugs, where the compiler accepts programs that should be rejected during type checking. In this work, we present an empirical study of 30 issues that report potential soundness bugs in rustc, collected from the GitHub issue tracker between January 1, 2022 and September 1, 2025. We analyze each issue in depth, focusing on its affected feature, symptom (how the feature is mishandled), consequence (the resulting undesirable behavior), triggering features, community consensus regarding whether it is a bug, and lifecycle, including introduction, discovery, and fix. Furthermore, we investigate existing artifacts, including implementations such as AddressSanitizer, Miri, Chalk, and a-mir-formality, alongside documentation such as the Rust Reference, the FLS, and Rust RFCs to assess their potential as oracles for testing the type soundness of rustc. Our key findings indicate that: (1) Certain soundness bugs, typically triggered by implied bounds or trait objects, compromise memory safety. (2) Sound type checking is challenged by edge cases involving associated types and the interaction between lifetimes and traits. (3) Most bugs persist from the initial introduction of the relevant features and require significant time to be discovered. (4) While AddressSanitizer and Miri can detect soundness bugs that lead to memory bugs, a-mir-formality and Chalk are currently immature despite their potential to identify other bug categories. (5) Existing documentation frequently fails to provide precise explanations of the language semantics.
— The Rust programming language provides stronger guarantees about memory safety than C. Therefore, translating C to Rust is one way to reduce security vulnerabilities. One common translation strategy uses LLM queries. We present an alternative agentic approach that gives an LLM freedom and guardrails, and a publicly available implementation named ACTOR that outperforms all previous tools. When programming in C, a programmer must manually manage memory and other resources, such as by calling free after each call to malloc or by calling fclose after each call to fopen . It is easy to violate these rules, leading to memory corruption, resource exhaustion, and security vulnerabilities. This is a serious problem, because much of the world’s critical software infrastructure is written in C. The systems programming language Rust is a promising replacement for C. Rust prevents many errors via compile-time analyses, such as for type-checking and ownership. There is a growing movement to replace software written in C by safer versions written in Rust. To date, that replacement has required manual rewriting, which is time-consuming, costly, and unscalable. An alternative approach is to automatically translate C to Rust. Previous C-to-Rust translation tools fall into three categories. Rule-based transpilers like C2Rust [3], Crown [14], and Laertes [2] use language-specific AST transformations and are pinned to specific compiler versions. They break when the input does not match their expectations and cannot be adapted to other language pairs without a complete rewrite. Since they largely target a Rust-specific problem, unsafe blocks, their ideas may not even generalize to other target languages. LLM-assisted translators like SmartC2Rust [13] and C2SaferRust [6] use LLMs for code generation but wrap them in substantial language-specific infrastructure: AST parsers, macro transformers, error-code classifiers, and language-specific segmentation (splitting the C program into small pieces before translating, using knowledge
Benedikt Schesch, Michael D. Ernst· IEEE Security & Privacy· 0 citations
SNIPTEST is an execution-based warning triage framework that generates and fuzzes compiled code slices centered around static-analysis warnings that employs a layer-by-layer slicing strategy, incrementally expanding context around the target location to validate potential vulnerabilities with increasing precision.
Aniruddhan Murali, Noble Saji Mathews, Mahmoud Alfadel et al.· IEEE Transactions on Softwar...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
