CVE-2026-6654
Double-Free and Use-After-Free in thin_vec Causes Panic
Publication date: 2026-04-20
Last updated on: 2026-04-20
Assigner: Mozilla Corporation
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| mozilla | thin_vec | 0.2.15 |
| mozilla | thin_vec | 0.2.16 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-415 | The product calls free() twice on the same memory address. |
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability involves a Double-Free or Use-After-Free (UAF) issue in the thin_vec crate, specifically in the `IntoIter::drop` and `ThinVec::clear` functions. The problem arises because a panic in the `ptr::drop_in_place` function causes the length to not be set to zero, which can lead to memory being freed twice or accessed after it has been freed.
How can this vulnerability impact me? :
This vulnerability can lead to memory corruption issues such as double-free or use-after-free errors. These issues can cause program crashes, unexpected behavior, or potentially allow an attacker to execute arbitrary code or escalate privileges if exploited.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing crashes or panics related to the thin_vec crate, especially when dropping iterators or clearing ThinVec instances containing elements whose Drop implementations may panic.
Using Rust's nightly toolchain with Miri or AddressSanitizer (ASAN) can help detect undefined behavior, heap-use-after-free, and double free errors caused by this vulnerability.
Suggested commands include running tests or reproducing the issue under Miri or ASAN to catch memory safety violations:
- Run tests with Miri: `cargo +nightly miri test`
- Run tests with AddressSanitizer enabled: `RUSTFLAGS='-Z sanitizer=address' cargo +nightly test`
Monitoring logs for panics during element drop in thin_vec usage and checking for double free or use-after-free errors in runtime diagnostics can also help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the thin_vec crate to version 0.2.16 or later, where the vulnerability is fixed by implementing a DropGuard pattern or pre-zeroing the length before dropping elements.
If upgrading is not immediately possible, avoid using `IntoIter::drop` or `ThinVec::clear` on collections containing elements whose Drop implementations may panic.
Review and refactor code to ensure that Drop implementations do not panic, reducing the risk of triggering the vulnerability.
Additionally, consider adding runtime checks or wrappers to safely handle panics during element drops to prevent double free or use-after-free conditions.