Double-Free / Use-After-Free (UAF) in the `IntoIter::drop` and `ThinVec::clear` functions in the thin_vec crate. A panic in `ptr::drop_in_place` skips setting the length to zero.

Affected: crates.io: thin-vec

### Summary

A **Double Free / Use-After-Free (UAF)** vulnerability has been identified in the `IntoIter::drop` and `ThinVec::clear` implementations of the `thin_vec` crate. Both vulnerabilities share the same root cause and can trigger memory corruption using only safe Rust code — no `unsafe` blocks required. Undefined Behavior has been confirmed via **Miri** and **AddressSanitizer (ASAN)**.

---

### Details

Both vulnerabilities share the same root cause. When a **panic occurs** during sequential element deallocation, the subsequent length cleanup code (`set_len(0)`) is never executed. During stack unwinding, the container is dropped again, causing already-freed memory to be re-freed (Double Free / UAF).

#### Vulnerability 1 — `IntoIter::drop`

**Location:** `thin-vec/src/lib.rs` L.2308~2314

`IntoIter::drop` transfers ownership of the internal buffer via `mem::replace`, then sequentially frees elements via `ptr::drop_in_place`. If a panic occurs during element deallocation, `set_len_non_singleton(0)` is never reached. During unwinding, `vec` is dropped again, re-freeing already-freed elements. The standard library's `std::vec::IntoIter` prevents this with a **DropGuard pattern**, but thin-vec lacks this defense.

```rust // Problematic structure (conceptual representation) impl<T> Drop for IntoIter<T> { fn drop(&mut self) { let mut vec = mem::replace(&mut self.vec, ThinVec::new()); unsafe { ptr::drop_in_place(vec.remaining_slice_mut()); /…

Affected: crates.io: thin-vec

A Double Free / Use-After-Free (UAF) vulnerability has been identified in the `IntoIter::drop` and `ThinVec::clear` implementations of the `thin-vec` crate. Both vulnerabilities share the same root cause and can trigger memory corruption using only safe Rust code - no unsafe blocks required. Undefined Behavior has been confirmed via Miri and AddressSanitizer (ASAN).

## Details

When a **panic occurs** during sequential element deallocation, the subsequent length cleanup code (`set_len(0)`) is never executed. During stack unwinding, the container is dropped again, causing already-freed memory to be re-freed (Double Free / UAF).

### Vulnerability 1 - `IntoIter::drop`

`IntoIter::drop` transfers ownership of the internal buffer via `mem::replace`, then sequentially frees elements via `ptr::drop_in_place`. If a panic occurs during element deallocation, `set_len_non_singleton(0)` is never reached. During unwinding, `vec` is dropped again, re-freeing already-freed elements. The standard library's `std::vec::IntoIter` prevents this with a **DropGuard pattern**, but thin-vec lacks this defense.

### PoC

```rust use thin_vec::ThinVec;

struct PanicBomb(String);

impl Drop for PanicBomb { fn drop(&mut self) { if self.0 == "panic" { panic!("panic!"); } println!("Dropping: {}", self.0); } }

fn main() { let mut v = ThinVec::new(); v.push(PanicBomb(String::from("normal1"))); v.push(PanicBomb(String::from("panic"))); // trigger e…

Affected: Ubuntu:24.04:LTS: rust-thin-vec, Ubuntu:25.10: rust-thin-vec, Ubuntu:26.04:LTS: rust-thin-vec

Double-Free / Use-After-Free (UAF) in the `IntoIter::drop` and `ThinVec::clear` functions in the thin_vec crate. A panic in `ptr::drop_in_place` skips setting the length to zero.