High-severity thin-vec bug risks memory corruption in safe Rust code

A high-severity flaw in thin-vec turned an ordinary panic into memory corruption. The advisory, published on April 14 and updated April 15, covered versions below 0.2.16 and showed that safe Rust code alone could hit a use-after-free and double-free path when element destruction panicked. GitHub said the behavior was confirmed with both Miri and AddressSanitizer, which is the kind of proof that makes a small utility crate suddenly look like a supply-chain risk instead of a niche footnote.

The bug lived in two cleanup paths: IntoIter::drop and ThinVec::clear. In both cases, a panic during element deallocation could prevent the length-reset step from running. That left the container in an inconsistent state, so unwinding could come back through the object again and free memory that had already been freed. The standard library’s std::vec::IntoIter avoids this class of bug with a DropGuard pattern, and the thin-vec advisory called out that missing protection directly. The patched release was 0.2.16.

That matters because ThinVec is not an obscure toy type. It is a Vec-like container that stores its length and capacity inline, so it takes up less space than Vec, and its documentation says it exists mainly to facilitate Gecko and Firefox FFI. When built in Gecko, it matches nsTArray’s memory layout and allocation strategy. In other words, this is the kind of dependency that lands in performance-sensitive code where people trust Rust’s ownership model and do not expect a destructor panic to cross the line from correctness bug into memory safety bug.

The practical response is simple: move to 0.2.16 and audit any cleanup code that assumes unwinding is harmless. Pay special attention to iteration, draining, clearing, and bulk deletion paths, especially where a transitive destructor could panic even if your own code never does. This is not a one-off pattern. RustSec has recorded similar panic-driven memory-safety bugs in safe APIs before, including telemetry’s vec_with_size() and rocket’s uri::Formatter, alongside other advisories in qwutils, slice-deque, and through. RustSec, maintained by the Rust Secure Code Working Group for crates.io advisories, exists because bugs like this keep showing up in places developers thought were already safe.