Why fuzzing still matters in memory-safe languages
This article is part of a four-part series on fuzzing in memory-safe languages.
Memory-safe languages like Rust and Go eliminate buffer overflows and use-after-free bugs by design. Yet fuzzing remains critical for finding the bugs that type systems can’t catch.
Beyond Memory Safety
Rust’s borrow checker and Go’s garbage collector prevent entire classes of vulnerabilities. But real-world software faces other failure modes:
- Performance issues: Algorithmic complexity attacks, resource exhaustion.
- Panics and crashes: Assertion failures, integer overflows, stack overflows.
- Logic errors: Incorrect algorithms that produce wrong results.
- Concurrency bugs: Race conditions, deadlocks, data races.
The Trophy Case
Rust’s trophy case demonstrates fuzzing’s continued relevance. Fuzzers have found critical bugs in:
- serde_json: Panic on malformed UTF-8 sequences.
- image: Integer overflow in PNG decoder.
- regex: Exponential backtracking on crafted inputs.
- tokio: Deadlock in async runtime.
These aren’t always memory corruption bugs - they are logic flaws that escaped review and testing.
Google’s OSS-Fuzz Expansion
Google’s OSS-Fuzz project has expanded beyond C/C++ to include languages such as Rust and Go, underscoring fuzzing’s broader applicability.
As noted in the Google Security Blog post “Fuzzing beyond memory corruption: Finding broader classes of vulnerabilities automatically”, fuzzing has considerable untapped potential to uncover more than just memory corruption bugs.
Rust projects integrated with OSS-Fuzz typically use tools like cargo-fuzz (built on libFuzzer), and many real-world bugs in Rust crates have been identified this way. Likewise, Go’s built-in fuzzing support has revealed issues in both the standard library and widely used packages.
Why Fuzzing Works
Fuzzing excels at exploring unexpected input combinations. As Brian Kernighan famously observed: “The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” Fuzzing automates the “what if” scenarios developers rarely consider.
Traditional testing focuses on expected inputs. Fuzzing throws everything at the wall to see what sticks, uncovering edge cases in:
- Input parsing and validation
- State machine transitions
- Resource allocation patterns
- Error handling paths
The Modern Context
Memory safety is a baseline, not a destination. Rust and Go provide strong foundations, but complex software still requires systematic exploration of its behavior space.
Property-based testing frameworks like proptest for Rust and Gopter for Go provide structured approaches to generating test cases that systematically explore edge cases.
Fuzzing complements static analysis and formal verification by providing empirical evidence of robustness, exercising software under adversarial conditions to reveal counterexamples that other methods may miss.