RUSTSEC-2026-0301: Double free in `StackVec::retain` when a predicate or element `Drop` panics

What to do

1. See which version you have: cargo tree -i stack_collections (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p stack_collections. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example stack_collections = "0.3.3") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

Summary

StackVec::retain committed its new length to self.len only after its internal loop completed. If the retain predicate or a removed element's Drop implementation panicked before the loop finished, unwinding proceeded with self.len still equal to the original, pre-retain length, leaving either a duplicated or already-destroyed element inside 0..len. StackVec's own Drop then revisited that slot, causing a double-drop (and for heap-owning types, a double-free).

Impact

Affects StackVec<T, CAP>::retain for T: Drop types where the predicate or the removed element's destructor can panic, on builds with unwinding enabled (panic = "unwind"). no_std/panic = "abort" builds cannot trigger this, since unwinding never occurs.

Patch

Fixed in 0.3.3 using an unwind-safe backshift guard, matching the approach alloc::vec::Vec::retain uses.

References

• Package: crates.io/crates/stack_collections
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0301.html
• Web: github.com/OverwrittenCode/stack_collections/pull/4

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.