RUSTSEC-2026-0298None▾ SunlitUse-after-free when a future's `Drop` panics while the container is dropped
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
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.
Update to 0.10.3.
unicycle >= 0.0.0-0, < 0.10.3Upgrade to a patched release:
unicycle 0.10.3