Cve-rs: Fast memory vulnerabilities, written in safe Rust

Original Article ↗ Hacker News Discussion ↗

A proof‑of‑concept Rust crate, cve-rs, exploits a long‑standing compiler soundness bug in Rust’s lifetime and variance system to create memory‑safety violations in code that contains no `unsafe` blocks. Commenters unpack how implied lifetime bounds, function pointer variance, and the current trait solver interact to permit this edge‑case, and note that Miri can detect the issue even though rustc accepts the code. The exchange weighs how rare and contrived such bugs are against Rust’s marketing as a “memory‑safe” language, and whether unsound corner cases meaningfully undermine that guarantee in practice.

Rust lifetime syntax and the core bug

  • Discussion centers on how &'a &'b T differs from adding an explicit where 'b: 'a bound.
  • Several comments explain: nested references create implied lifetime bounds that the compiler should respect; the outer lifetime must not outlive the inner.
  • The bug arises when these implied bounds interact with function pointer variance and higher-ranked lifetimes: the compiler can incorrectly assume a lifetime outlives another after certain casts, enabling a use-after-free in “safe” code.
  • Some emphasize this is about late-bound vs early-bound lifetimes and how variance (contra-/covariance) is handled for function types.

Miri, Polonius, and trait solver work

  • Miri (an interpreter/sanitizer) detects the unsoundness at runtime, even when Rust code is syntactically “safe.”
  • There is debate whether a new trait solver and related refactors (implied bounds, coinduction) are prerequisites for a proper fix; links note this bug is explicitly blocked on that work.
  • Some are skeptical of “new solver will fix it” narratives but others note there is a clear technical plan, just hard and slow.

Safety guarantees, unsoundness, and marketing

  • One side argues: even with 80+ open “unsound” issues, Rust is far safer than C/C++, and these are rare edge cases, often difficult to hit accidentally.
  • Others counter: any unsoundness undermines claims of “memory safety”; Rust should be described as “memory safer” until such bugs are fixed.
  • There’s discussion over whether this is a compiler bug vs a deeper language/type-theory flaw; some insist the design can be made sound but the implementation lags.

Ergonomics and learnability

  • Some readers find the bug-triggering code terrifying or unreadable and worry Rust is too “symbol heavy” and RSI-inducing.
  • Others respond that this is obfuscated, minimal-repro style code, not representative of typical Rust, and that most real code has few explicit lifetimes.
  • Lifetimes are explained informally as “memory pools” with labels, which several find clarifying.
  • There is broader criticism and defense of Rust syntax choices, with suggestions that some unsafe-related syntax and function syntax could have been designed better.

Practical impact and exploitability

  • Many stress that exploiting this requires contrived code and anti-optimization tricks; it’s unlikely to be written accidentally.
  • Still, commenters note that even a single such hole contradicts the expectation that safe Rust code cannot cause memory corruption, and should be taken seriously.
  • Comparison is made to other avenues like /proc/self/mem, with a reminder that Rust’s guarantees only cover what the program itself does, not external processes or the OS.

Miscellaneous

  • The project’s joke license (GLWTS) and a download_more_ram() function are noted as humorous touches.
  • Someone asks about the shell prompt; others identify it as a popular prompt tool.