flawopen.com/インシデント/Rust unsafe & smallvec
ロボットが棚の強度を完璧に点検するため絶対に荷崩れしない倉庫があります。しかし一部の作業だけロボットを切り、人間が手作業で行っていました。作業員は配達員に「大体何箱？」と尋ね、その推測だけで棚を作って積み始めました。実際には約束より多くの荷物が届き、棚から溢れた荷物が床に散乱してしまいました。
Illustrative reconstruction of the pattern, not the crate's literal source. The upstream fix reserved additional space per inserted item and simplified the implementation specifically so its correctness would be easier to verify.
Rust's memory-safety guarantee is real but conditional, and the condition is usually stated imprecisely. The accurate formulation is: safe Rust cannot cause undefined behaviour, provided every unsafe block it depends on is sound.
That shifts where the risk lives rather than eliminating it. In C, memory-safety bugs can appear anywhere in millions of lines. In Rust, they can only originate inside unsafe blocks — typically a very small fraction of a codebase. This is an enormous practical improvement: it makes the auditable surface small enough to actually audit. But "small" is not "zero", and a soundness bug inside that surface is exploitable exactly like its C equivalent, as the CVSS 9.8 here reflects.
There is a second, subtler point. unsafe is not locally contained. An unsound unsafe block poisons every safe API built on top of it — which is why this bug affected callers who never wrote the keyword.
// SAFETY: comment. Stating exactly what must hold and why it does is what makes later review possible. Unexplained unsafe is unreviewable unsafe.cargo audit checks against the RustSec database. Most unsafe code in a typical project lives in crates someone else wrote.No — it means they are conditional in a way worth understanding precisely. Rust confines memory-safety defects to a small, explicitly marked, auditable portion of a codebase, which is a substantial structural improvement over a language where any line can contain one. The claim that survives scrutiny is "dramatically smaller attack surface", not "no attack surface".
Yes — that is what unsafe trait is for. Implementing one is an explicit promise that carries safety obligations, which lets unsafe code rely on it. The standard library's TrustedLen exists for exactly this iterator-length problem, though it remains unstable.
cargo geiger reports unsafe usage across a dependency tree, and cargo audit flags known advisories. Neither proves soundness, but together they show you where the risk is concentrated.