CVE-2026-6654: thin_vec Crate Use-After-Free Vulnerability

CVE-2026-6654 Overview

CVE-2026-6654 is a Double-Free / Use-After-Free (UAF) memory corruption vulnerability affecting the thin_vec Rust crate, specifically in the IntoIter::drop and ThinVec::clear functions. The vulnerability occurs when a panic in ptr::drop_in_place causes the code to skip setting the length to zero, potentially allowing subsequent operations to access freed memory or trigger a double-free condition.

Critical Impact

This memory safety vulnerability in a popular Rust crate could lead to memory corruption, potentially enabling information disclosure or integrity violations in applications that depend on thin_vec.

Affected Products

• thin_vec Rust crate (vulnerable versions)
• Applications and libraries dependent on thin_vec
• Mozilla projects utilizing thin_vec for memory-efficient vector storage

Discovery Timeline

• 2026-04-20 - CVE CVE-2026-6654 published to NVD
• 2026-04-20 - Last updated in NVD database

Technical Details for CVE-2026-6654

Vulnerability Analysis

This vulnerability is classified as CWE-415 (Double Free), a memory corruption flaw that occurs when the same memory address is freed more than once. In the context of thin_vec, the issue manifests in two key functions: IntoIter::drop and ThinVec::clear.

The core problem stems from improper state management during panic unwinding. When iterating over elements or clearing a ThinVec, if a Drop implementation for one of the contained elements panics during ptr::drop_in_place, the code path that would normally set the vector's length to zero is bypassed. This leaves the vector in an inconsistent state where it still reports containing elements that have already been dropped.

The vulnerability requires local access to exploit and could potentially be triggered by crafting specific element types with panicking Drop implementations. Successful exploitation could lead to limited confidentiality and integrity impacts through memory corruption.

Root Cause

The root cause is insufficient exception safety handling in the IntoIter::drop and ThinVec::clear implementations. When ptr::drop_in_place is called to destroy elements, a panic can cause the function to exit early without executing the critical cleanup code that sets the length field to zero. This violates the invariant that a vector's length should always reflect the number of valid, non-dropped elements.

In safe Rust code, this type of memory corruption should be prevented by the language's ownership system. However, the thin_vec crate uses unsafe code internally for performance optimization, and the unsafe blocks did not properly account for panic unwinding scenarios.

Attack Vector

The vulnerability has a local attack vector, requiring the attacker to execute code in the same process or system where the vulnerable thin_vec code is running. An attacker could exploit this by:

1. Constructing a type with a Drop implementation that panics under specific conditions
2. Storing instances of this type in a ThinVec
3. Triggering iteration or clearing operations on the vector
4. Catching the panic with std::panic::catch_unwind
5. Accessing the vector again, causing use-after-free or double-free conditions

The vulnerability mechanism involves panic unwinding bypassing critical cleanup code in the IntoIter::drop and ThinVec::clear functions. When a panic occurs during ptr::drop_in_place, the vector's length is not properly zeroed out, leaving the data structure in an inconsistent state that can lead to memory corruption. For detailed technical analysis, see the GitHub Security Advisory.

Detection Methods for CVE-2026-6654

Indicators of Compromise

• Unexpected program crashes or memory corruption errors in Rust applications using thin_vec
• Double-free or use-after-free detection from memory sanitizers (ASan, Valgrind)
• Panic messages referencing IntoIter::drop or ThinVec::clear in stack traces
• Unexplained behavior after catching panics in code paths involving ThinVec operations

Detection Strategies

• Run applications with AddressSanitizer (ASan) enabled to detect double-free and use-after-free conditions
• Audit Cargo.lock files for vulnerable versions of the thin_vec dependency
• Use cargo audit to automatically identify vulnerable crate versions in Rust projects
• Implement fuzz testing with panic-inducing Drop implementations to identify affected code paths

Monitoring Recommendations

• Monitor application logs for panic messages involving thin_vec operations
• Implement runtime memory corruption detection in production environments where feasible
• Track dependency updates for thin_vec and other memory-critical Rust crates
• Set up automated security scanning in CI/CD pipelines using tools like cargo-deny and cargo-audit

How to Mitigate CVE-2026-6654

Immediate Actions Required

• Audit all Rust projects to identify usage of the vulnerable thin_vec crate versions
• Update to the patched version of thin_vec as soon as it becomes available
• Review code that uses ThinVec with types that have complex Drop implementations
• Consider temporarily replacing thin_vec with the standard library Vec if updates are not yet available

Patch Information

Security updates and patching information are available through the GitHub Security Advisory. Users should monitor this advisory for patched version releases and update their Cargo.toml dependencies accordingly.

Workarounds

• Avoid using ThinVec with types that may panic in their Drop implementations
• Wrap potentially panicking Drop logic with std::panic::catch_unwind inside the Drop implementation itself
• Use std::mem::ManuallyDrop to manually control when elements are dropped in critical code paths
• Consider using the standard library Vec as an alternative until a patched version is available

# Update thin_vec in Cargo.toml to patched version
# Check current version
cargo tree -p thin-vec

# Update to latest version
cargo update -p thin-vec

# Verify the vulnerability is addressed
cargo audit