LLMs struggle with unsafe Rust: six months of testing revealed critical errors

The author had LLM write unsafe Rust code in production projects for six months and verified each block with Miri and sanitizers. The result was disappointing: models made the same errors predictably and consistently.

Seven categories of LLM errors in unsafe Rust

Models consistently make errors in the same locations:

• Aliasing — violation of the non-overlapping references rule
• Provenance — attempts to use improperly obtained pointers
• Layout in alloc/dealloc — size/alignment mismatch during allocation and deallocation
• ManuallyDrop — forget to call drop or access the object after drop
• Race conditions in FFI callbacks — race conditions when calling C functions from threads
• Manual Send/Sync — incorrectly implement thread safety traits
• Uninit memory — treat uninitialized data as initialized

Why Miri revealed the problems

Miri is a Rust interpreter that tracks undefined behavior. When LLM generates code with subtle violations at first glance (for example, a temporary pointer with incorrect provenance), the regular compiler misses it, but Miri catches it. Under sanitizers (AddressSanitizer, ThreadSanitizer), race conditions and use-after-free were uncovered, which may not appear in regular tests.

"Each category comes with a minimal example and 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 errors in memory management and multithreading. For critical code (system software, system libraries), unsafe Rust from models must be checked with Miri.