GHSA-rvr2-r3pv-5m4p
There is a race condition that can lead to a use-after-free if a `oneshot::Receiver` is polled but then dropped instead of polled to completion. This could happen if the receiver future was cancelled while receiving, for example by being wrapped in a timeout future or similar. When the `Receiver` is polled (`Future::poll`) it writes a waker to the channel and sets it to the `RECEIVING` state. If the `Receiver` was then dropped (instead of polled to completion), the `Drop` implementation on `Receiver` unconditionally swapped the channel state to `DISCONNECTED` and only after doing so it read back its waker from the heap allocation and dropped it. The problem is that the `DISCONNECTED` state could be observed by the `Sender`, which would lead to it deallocating the channel heap memory. If the `Sender` manage to free the channel before the `Receiver` managed to proceed to dropping the waker, then the `Receiver` would read from the freed channel memory (Use After Free). The fix was submitted in https://github.com/faern/oneshot/pull/74 and published as part of `oneshot` version `0.1.12`.
Properties
- ghsa_id
- GHSA-rvr2-r3pv-5m4p
- summary
- oneshot has potential Use After Free when used asynchronously
- severity
- high
- cve_id
- GHSA-rvr2-r3pv-5m4p
- is_ghsa_only
- true
- ghsa_published
- 2026-01-27T00:59:04Z
- source_url
- https://github.com/advisories/GHSA-rvr2-r3pv-5m4p
- ghsa_updated
- 2026-01-27T00:59:08Z
Related Entities (4)
HAS_WEAKNESS (2)
REPORTED_BY (1)
AFFECTS (1)
Explore deeper with Ninja Signal's threat intelligence graph