GHSA-8gw6-724c-9h38 json
Use-after-free when a future's `Drop` panics while the container is dropped
published 2026-09-12 57 d ago modified 2026-09-22 47 d ago also RUSTSEC-2026-0298
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
`Storage::clear` walks the slab, empties each entry and frees the `Task` allocation once its reference count reaches zero. `self.tasks.set_len(0)` only runs after the loop.
Emptying an entry drops the user future it holds, and `T` carries no bounds excluding a panicking `Drop`. If one unwinds, the length is never committed and `self.tasks` still holds the pointers already processed. `Drop for Storage` calls `clear` again, and the second pass dereferences `(*task.as_ptr()).entry` on allocations the first pass already freed — a use-after-free (CWE-416) reachable from safe Rust.
`Storage` is reached only through `Unordered`, whose `Drop` calls `clear`. No particular method call is needed; dropping the container is enough.
## Mitigation
Update to 0.10.3.
Patch / fix
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | unicycle | >=0.0.0-0, <0.10.3 |
0.10.3 |
References
Sources
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.