Skip to content

← Public intelligence

crates.io package

unicycle

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Unratedcrates.ioPublished

    Use-after-free when a future's Drop panics while the container is dropped

    GHSA-8gw6-724c-9h38

    Affected
    • crates.io unicycle >= 0.0.0-0, < 0.10.3
    Fixed in
    0.10.3· Vendor fix available
    Issue
    `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.

    Recommended action: Upgrade to 0.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.devSource checked Evidence →
  2. High, CVSS 8.1crates.ioPublished

    Data races in unicycle

    CVE-2020-36436 · GHSA-686f-ch3r-xwmh

    Affected
    • crates.io unicycle < 0.7.1
    Fixed in
    0.7.1· Vendor fix available
    Issue
    Affected versions of this crate unconditionally implemented Send & Sync for types PinSlab<T & Unordered<T, S. This allows sending non-Send types to other threads and concurrently accessing non-Sync types from multiple threads. This can result in a data race & memory corruption when types that provide internal mutability without synchronization are contained within PinSlab<T or Unordered<T, S and accessed concurrently from multiple threads. The flaw was corrected in commits 92f40b4 & 6a6c367 by adding trait bound T: Send to Send impls for PinSlab<T & Unordered<T, S and adding T: Sync to Sync impls for PinSlab<T & Unordered<T, S.

    Recommended action: Upgrade to 0.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →