flawopen.com/घटनाएं (Incidents)/Rust unsafe & smallvec

जब 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.

What this says about Rust's guarantee

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.

The rules for writing unsafe correctly

• ✓Assume every safe input is adversarial. Soundness means holding for all possible safe code, including a deliberately hostile size_hint, a Deref that returns something different each call, or a comparator that is not a total order.
• ✓Never derive a memory bound from a safe trait method. If safe code can influence a length, capacity or offset used by unsafe code, re-validate it against reality before every write.
• ✓Watch for panic safety. If user code runs inside your unsafe region — a Drop impl, an iterator's next, a closure — it can panic and unwind mid-operation, leaving your structure in a state your invariants forbid.
• ✓Document the invariant in a // SAFETY: comment. Stating exactly what must hold and why it does is what makes later review possible. Unexplained unsafe is unreviewable unsafe.
• ✓Minimise the block, not just the count. Wrapping a whole loop in unsafe to avoid repeating the keyword expands the region a reviewer must reason about. Narrow blocks localise the obligation.
• ✓Run Miri in CI. The interpreter detects a large class of undefined behaviour — out-of-bounds access, use-after-free, invalid aliasing — that ordinary tests pass straight through.
• ✓Audit your dependency tree for advisories. cargo audit checks against the RustSec database. Most unsafe code in a typical project lives in crates someone else wrote.

FAQ

Related reading

• Heartbleed: one missing bounds check, half the internet
• Baron Samedit: ten years of root hidden in a backslash
• Citrix Bleed: how misreading one return value bypassed MFA

स्रोत और आधिकारिक एडवाइजरी

• RustSec — RUSTSEC-2021-0003: buffer overflow in SmallVec::insert_many
• NVD — CVE-2021-25900 detail
• servo/rust-smallvec — issue #252, the original report
• The Rustonomicon — the guide to unsafe Rust
• Rust std — Iterator::size_hint and its contract
• Miri — an interpreter that detects undefined behaviour in Rust
• CWE-787 — Out-of-bounds Write