VDB
KO

RUSTSEC-2026-0267

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

Details

`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](https://github.com/LukasKalbertodt/stable-vec/security/advisories/GHSA-mr2v-63pc-gmr4) and the 0.4.3 changelog for the full list.

Are you affected?

Enter the version of the package you're using.

Affected packages

crates.io / stable-vec
Introduced in: 0.0.0-0 Fixed in: 0.4.3

Upgrade stable-vec to 0.4.3 or newer (ecosystem crates.io).

References