---
id: RUSTSEC-2026-0252
title: 'Panic-safety unsoundness in `SplitVec::extend_from_slice` (uninitialized read)'
summary: 'Panic-safety unsoundness in `SplitVec::extend_from_slice` (uninitialized read)'
severity: none
vendor: orx-split-vec
product: orx-split-vec
ecosystem: rust
affected:
  - 'orx-split-vec >= 0.0.0-0, < 4.0.0'
patched:
  - orx-split-vec 4.0.0
published: '2026-08-11'
updated: '2026-08-11'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/RUSTSEC-2026-0252'
references:
  - url: 'https://crates.io/crates/orx-split-vec'
  - url: 'https://rustsec.org/advisories/RUSTSEC-2026-0252.html'
  - url: 'https://github.com/orxfun/orx-split-vec/issues/95'
tags:
  - osv
  - rust
ingestedAt: '2026-08-11T19:17:10.451Z'
---

## Overview

`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.

## Affected packages

- `orx-split-vec >= 0.0.0-0, < 4.0.0`

## Remediation

Upgrade to a patched release:

- `orx-split-vec 4.0.0`