RUSTSEC-2026-0292None▾ SunlitDouble free / use-after-free in `Chunk` and `InlineArray` removal methods when an element's `Drop` panics
▾ 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
Chunk::{clear, drop_left, drop_right} and InlineArray::{clear, truncate} drop the removed elements before updating the metadata that records which slots hold live values — the left/right index pair for Chunk, the length field for InlineArray. If an element's Drop panics during the drop, that update is never reached, so the collection still treats the already-dropped elements as live. When the collection is later dropped (its destructor walks the range described by the stale metadata), or a subsequent operation touches the same slots, those elements are dropped a second time — a double free (CWE-415) / use-after-free (CWE-416) reachable from safe Rust.
The stale field is left and right for Chunk::clear, left for drop_left, right for drop_right, and the length field for both InlineArray methods.
Upgrade to imbl-sized-chunks 0.2.0 or later, which commits the metadata before dropping any element (fixed in jneem/imbl-sized-chunks#14, released in 0.2.0).
imbl-sized-chunks >= 0.0.0-0, < 0.2.0Upgrade to a patched release:
imbl-sized-chunks 0.2.0