11 year old unsoundness bugs found in Rust borrow checker

Original Article ↗ Hacker News Discussion ↗

An 11‑year‑old soundness bug has been found in Rust’s borrow checker, where seemingly ordinary code involving lifetimes and a custom `Drop` implementation is wrongly accepted, allowing a reference to outlive the data it points to. Commenters unpack how this violates Rust’s core promise of memory safety, stress that it’s a compiler implementation error rather than a flaw in the language’s type system, and note that it appears to require a contrived destructor to turn into an actual exploit. The incident fuels broader debate about how “safe” Rust really is compared to C, the limits of any type system or formal proof, and the growing role of tools (including AI) in uncovering subtle compiler bugs.

Nature of the bug

  • Unsoundness in the borrow checker around T: 'static and Drop.
  • Minimal example: a generic struct Q<T: 'static>(Option<T>) with a Drop impl also bounded by 'static.
  • Compiler wrongly allows storing a non‑'static reference (e.g. &l with stack lifetime) in Q, which is supposed to contain only 'static data.
  • The destructor can then treat this as 'static, e.g. stash it in a global, enabling use‑after‑free.

Why it went unnoticed

  • Triggering pattern is considered unusual: needs a custom Drop plus lifetime bounds in a specific configuration.
  • Debate on how “normal” custom Drop is: some say rare, others say common, especially with FFI; but this exact pattern is rare.
  • Many invalid lifetime programs might never visibly crash, so the bug could be exercised without obvious failure.

Safety guarantees, soundness, and UB

  • Clarification:
    • Unsoundness = safe Rust can cause UB due to compiler/typechecker bugs.
    • UB in the spec = user steps outside well‑defined behavior.
  • This bug is in the compiler, not in Rust’s intended lifetime rules; fix is to reject such code.
  • Some note there are many open unsoundness issues; others stress that fixes can be shipped even in patch releases, and affected code was never “valid Rust”.

Comparisons with C and other languages

  • Some use this to argue Rust’s safety marketing is overstated or gives a false sense of security.
  • Others counter that C/C++ also have compiler bugs plus pervasive language‑level UB, so Rust still represents a major safety improvement.
  • Discussion that no language can be perfectly safe; goal is making classes of bugs impossible or extremely rare.

Formal methods and AI

  • References to ongoing efforts to formally specify/prove Rust or subsets of it.
  • Acknowledgment that even proof assistants, specs, and underlying math can be wrong, so absolute guarantees are impossible.
  • Some see AI/LLMs as promising tools for fuzzing/searching compilers for such bugs; others are skeptical or fatigued by AI hype.

Community and social dynamics

  • Complaints about Rust evangelism and perceived bashing of other languages versus defenses that official messaging is more measured.
  • Meta‑discussion about overreactions to individual bugs: some call for perspective—this is a real but narrow defect, not a wholesale failure of Rust’s model.