Skip to content

← Public intelligence

crates.io package

stable-vec

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Unratedcrates.ioPublished

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

    GHSA-mr2v-63pc-gmr4

    Affected
    • crates.io stable-vec >= 0.0.0-0, < 0.4.3
    Fixed in
    0.4.3· Vendor fix available
    Issue
    `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…

    Recommended action: Upgrade to 0.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.devSource checked Evidence →