thin-vec Double Free / Use-After-Free Vulnerability
A double free/use-after-free vulnerability exists in the `thin_vec` crate before version 0.2.16, specifically in the `IntoIter::drop` and `ThinVec::clear` implementations, which can be triggered via a panic during element deallocation, leading to memory corruption and potential arbitrary code execution.
A double free/use-after-free vulnerability has been identified in the thin_vec crate, affecting versions prior to 0.2.16. The vulnerability resides in the IntoIter::drop and ThinVec::clear implementations. The root cause is a failure to properly handle panics during element deallocation, leading to a double free when the container is dropped again during stack unwinding. This vulnerability can be triggered using safe Rust code, without requiring unsafe blocks. Miri and AddressSanitizer (ASAN) have confirmed the undefined behavior. Exploitation can lead to memory corruption and, when combined with Box<dyn Trait> types, potentially arbitrary code execution through heap spray and vtable hijacking. Defenders should be aware of the risk associated with using vulnerable versions of the thin_vec crate.
Attack Chain
- An application uses the
thin_veccrate version prior to 0.2.16. - The application creates a
ThinVeccontaining heap-owning types likeString,Vec, orBox. - Either
into_iter()is called, and the iterator is dropped before complete consumption, orclear()is directly invoked on theThinVec. - During the deallocation of elements (either in
IntoIter::droporThinVec::clear), theDropimplementation of one of the elements triggers a panic. - Due to the panic, the
set_len(0)function is not executed, leaving theThinVecwith an incorrect length. - The
ThinVecis dropped again during stack unwinding (in theIntoIter::dropcase) or when it goes out of scope (in theThinVec::clearcase). - The already-freed memory is freed again, resulting in a double free or use-after-free.
- If combined with
Box<dyn Trait>types, an attacker might be able to reclaim the freed memory with a fake vtable via heap spraying, potentially leading to arbitrary code execution.
Impact
This vulnerability can lead to memory corruption and denial of service. If the freed memory is reclaimed by an attacker, it could lead to arbitrary code execution, especially when combined with Box<dyn Trait> types. The vulnerability affects all code using the thin_vec crate prior to version 0.2.16. Successful exploitation requires specific conditions to be met, including the presence of heap-owning types in the ThinVec and a panic occurring during the Drop implementation of an element.
Recommendation
- Upgrade the
thin-veccrate to version 0.2.16 or later to remediate the vulnerability (https://github.com/advisories/GHSA-xphw-cqx3-667j). - If upgrading is not immediately feasible, carefully review the
Dropimplementations of types stored inThinVecto ensure they cannot panic. - Monitor application logs for unexpected panics during the deallocation of
ThinVecelements.
Detection coverage 2
Detect Panic in Drop Implementation (Generic)
mediumDetects a panic occurring within a drop implementation in Rust code, which can potentially lead to use-after-free or double-free vulnerabilities.
Detect ThinVec Usage Prior to Version 0.2.16
lowDetects the use of the `thin-vec` crate in Rust projects with versions prior to 0.2.16 by analyzing Cargo.lock files.
Detection queries are available on the platform. Get full rules →