RUSTSEC-2026-0298: Use-after-free when a future's `Drop` panics while the container is dropped

What to do

1. See which version you have: cargo tree -i unicycle (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p unicycle. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example unicycle = "0.10.3") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

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.

References

• Package: crates.io/crates/unicycle
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0298.html
• Web: github.com/udoprog/unicycle/commit/4f1492a266824f8aa66fd6b27fa6188bf826bdfd

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.

Other advisories for unicycle

• Vulnerability HighRUSTSEC-2020-0116 · 2020-11-15PinSlab<T> and Unordered<T, S> need bounds on their Send/Sync traits

Full security history of unicycle