Affected: Mozilla thin-vec, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux AI (RHEL AI) 3

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()); /…