Memory safety bugs in Rust std/core

Microsoft FORGE Lab reports memory-safety flaws in Rust’s standard library, where mistakes in unsafe implementation code can let entirely safe Rust trigger undefined behavior. Researchers used Hyenas, an AI-assisted vulnerability-scanning system, to identify candidates, then reproduced and assessed them before reporting them to Rust maintainers. The findings illustrate three recurring forms of misplaced trust: assuming code will not panic, assuming user-provided implementations behave correctly, and assuming the operating system or other underlying system state remains trustworthy. The work focuses on soundness bugs in std and core, not compiler flaws, and notes that some reported issues remained open at publication.

One example involves a fixed-size buffer whose clone method calls user-defined cloning code while the new buffer is uninitialized but already has a destructor; if cloning panics, cleanup treats uninitialized memory as valid. Another concerns custom allocators that unwind, exposing unsafe assumptions in allocation-related code and prompting the stabilized Allocator API to prohibit unwinding. A third flaw lets a custom, safe Pattern implementation supply a non-ASCII byte that str::replace mistakes for ASCII, producing an invalid UTF-8 String and enabling later undefined behavior. The discussion also cites related bugs in join and string search APIs, where safe trait implementations can return inconsistent data or ranges. The central lesson is that unsafe code must validate external behavior, preserve invariants across panics, and carefully account for system boundaries.