GHSA-xphw-cqx3-667j

### 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()); // ← panic may occur here vec.set_len_non_singleton(0); // ← unreachable on panic } // During unwinding, vec is dropped again → Double Free } } ``` #### Vulnerability 2 — `ThinVec::clear` `clear()` calls `ptr::drop_in_place(&mut self[..])` followed by `self.set_len(0)` to reset the length. If a panic occurs during element deallocation, `set_len(0)` is never executed. When the `ThinVec` itself is subsequently dropped, already-freed elements are fre