RUSTSEC-2026-0267: Panic-safety unsoundness in `BitVecCore::clear` (double-free / use-after-free)

What to do

1. See which version you have: cargo tree -i stable-vec (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p stable-vec. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example stable-vec = "0.4.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

BitVecCore::clear drops every occupied element with drop_in_place and only afterwards clears the occupancy bits and resets len. If an element's Drop panics, those metadata updates are skipped, so the slot of the already-dropped element stays marked as occupied. BitVecCore::drop calls clear() again, visits the same slot, and drops the element a second time , a double-free / use-after-free reachable from safe Rust.

Reachable via the public StableVec::clear and ExternStableVec::clear, which delegate to BitVecCore::clear.

Impact

• CWE-415 (Double Free): the same allocation is freed twice.
• CWE-416 (Use-After-Free): a freed allocation is accessed during a repeated Drop.

Reachable entirely from safe Rust via catch_unwind with element types whose Drop can panic. Confirmed under AddressSanitizer on 0.4.2.

Fix

Fixed in stable-vec 0.4.3 by removing each element via remove_at, which clears the occupancy bit before taking the value out.

Release 0.4.3 also fixes several other panic-safety issues found by the maintainer; see GHSA-mr2v-63pc-gmr4 and the 0.4.3 changelog for the full list.

References

• Package: crates.io/crates/stable-vec
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0267.html
• Web: github.com/LukasKalbertodt/stable-vec/pull/51

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