FORGE Lab uses agentic tools to identify memory safety issues in Rust

Microsoft's FORGE Lab has identified several memory safety issues in Rust's standard library, including cases where code written entirely in safe Rust can trigger undefined behavior. The research utilized Hyenas, FORGE's frontier research version of codename MDASH, an AI-powered vulnerability-scanning system.

The findings reveal three recurring patterns of misplaced trust in unsafe code: trusting code not to panic, trusting user-provided implementations to be correct, and trusting the underlying system. These vulnerabilities exist despite Rust's rich type system and ownership model that are designed to prevent memory-safety issues.

Growing Importance of Rust Safety

Rust's memory-safety guarantees are increasingly critical as the language becomes part of software used by billions of people daily. Microsoft has elevated Rust to Tier-1 internal language status alongside C++, C#, and TypeScript. Other major tech companies like GitHub, Bun, Android, Linux kernel, and Cloudflare are also adopting Rust for critical components.

Much of this software relies on Rust's foundational libraries, core and std, and the safety guarantees of the APIs they provide. Bugs in these libraries can have consequences that extend far beyond the code where they originate, potentially affecting systems that billions of people depend on.

Patterns of Safety Bugs

The research identified three specific patterns of misplaced trust in unsafe Rust code. First, trusting code not to panic can lead to vulnerabilities when unwinding exposes broken invariants. Second, trusting user-provided implementations to be correct can cause issues when safe but incorrect code is called. Third, trusting the underlying system can lead to problems when system assumptions are violated.

Panic Safety Challenges

One critical issue identified was in MapWindows::clone, where a panic safety vulnerability exists. The code breaks its own invariant during cloning, potentially causing crashes when destructors access uninitialized memory if a panic occurs. The fix involves holding the new buffer in ManuallyDrop until fully written.

The recently stabilized Allocator API also demonstrated these challenges. Custom allocators can break assumptions about allocation failures, leading to unsound behavior. The stabilization now requires implementors never to unwind from the trait's methods or from drop, as unwinding from allocation-related methods was found to be a pervasive source of unsoundness.