LLMs Struggle With Unsafe Rust: Six Months of Testing Reveal Critical Errors

The author had LLMs write unsafe Rust in production projects for six months and checked every block with Miri and sanitizers. The result was disappointing: the models make the same errors predictably and consistently.

Seven categories of LLM errors in unsafe Rust

The models keep failing in the same places:

• Aliasing — violating the rule on non-overlapping references
• Provenance — trying to use pointers obtained incorrectly
• Layout in alloc/dealloc — a mismatch in size/alignment between allocation and deallocation
• ManuallyDrop — forgetting to call drop, or using an object after drop
• Races in FFI callbacks — race conditions when C functions are called from threads
• Manual Send/Sync — incorrect implementations of thread-safety traits
• Uninit memory — treating uninitialized data as initialized

Why Miri exposed the problems

Miri is a Rust interpreter that tracks undefined behavior. When an LLM generates code with violations that are not obvious at first glance (for example, a temporary pointer with incorrect provenance), the regular compiler lets it through, while Miri catches it. Under sanitizers (AddressSanitizer, ThreadSanitizer), races and use-after-free bugs surfaced that may not show up in ordinary tests.

"Each category comes with a minimal example and a fix" — the author

shows that these are not just observations but reproducible error patterns.

What this means

LLMs are not yet ready to write unsafe Rust without human oversight. They generate syntax and general logic well, but systematically make mistakes when dealing with memory and multithreading. For critical code (system software, system libraries), unsafe Rust written by models must be checked under Miri.