RUSTSEC-2026-0301 json
Double free in `StackVec::retain` when a predicate or element `Drop` panics
published last mo. modified last mo.
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
## 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.
Patch / fix
Is RUSTSEC-2026-0301 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | stack_collections | >=0.3.0, <0.3.3 |
0.3.3 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.