GHSA-rvr2-r3pv-5m4p
oneshot has potential Use After Free when used asynchronously
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
What each source reports
GitHub Advisories Score used 8.2
oneshot has potential Use After Free when used asynchronously
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.
- Record
GHSA-rvr2-r3pv-5m4p- CVSS 4.0
- 8.2 High
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-362, CWE-416
- Updated
- 2026-11-02
OSV 8.2
oneshot has potential Use After Free when used asynchronously
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.
- Record
GHSA-rvr2-r3pv-5m4p- CVSS 4.0
- 8.2 High
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-362, CWE-416
- Updated
- 2026-11-02
OSVRUSTSEC-2026-0005No score
Potential use-after-free in `oneshot` when used asynchronously
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.
- Record
RUSTSEC-2026-0005- Updated
- 2026-11-02
Affected packages
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
GHSA-rvr2-r3pv-5m4p is a high vulnerability (CVSS 8.2) in oneshot, published January 25, 2026. No source lists public exploit code. Fixed in oneshot 0.1.12.