RUSTSEC-2026-0252 json
Panic-safety unsoundness in `SplitVec::extend_from_slice` (uninitialized read)
published 3mo ago modified 3mo ago
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
`SplitVec::extend_from_slice` increments the logical length `self.len` before cloning the incoming elements into the reserved slots. If an element's `Clone` panics mid-fill, unwinding leaves `self.len` counting slots that were never initialized. A later safe read (`get`, indexing, `iter`) then reads one of those uninitialized slots.
This is reachable from safe Rust — a read of uninitialized memory (CWE-908). It is not a double-free: `SplitVec` has no manual `Drop` and its elements live in a standard `Vec`, so the defect is a read, not a free.
## Impact
A safe read after the panic returns a value built from uninitialized bytes. For a heap-owning element type such as `String`, the resulting value has garbage length/pointer fields.
Confirmed under Miri. AddressSanitizer stays silent for this class, since the uninitialized bytes are consumed as a non-dereferenced field rather than an invalid load or free.
## Fix
Fixed in `orx-split-vec` 4.0.0, which no longer commits the length before the elements are cloned.
Patch / fix
- crates.io orx-split-vec 4.0.0
Is RUSTSEC-2026-0252 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | orx-split-vec | >=0.0.0-0, <4.0.0 |
4.0.0 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.