RUSTSEC-2026-0267None▾ SunlitPanic-safety unsoundness in `BitVecCore::clear` (double-free / use-after-free)
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
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.
Drop.Reachable entirely from safe Rust via catch_unwind with element types whose
Drop can panic. Confirmed under AddressSanitizer on 0.4.2.
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.
stable-vec >= 0.0.0-0, < 0.4.3Upgrade to a patched release:
stable-vec 0.4.3