Every CVESearch/Get API key

GHSA-rvr2-r3pv-5m4p

oneshot has potential Use After Free when used asynchronously

8.2 HighFix available

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 used8.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 HighCVSS: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
OSV8.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 HighCVSS: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

Affected packages
PackageAffectedFixed
oneshot
crates.io
before 0.1.12
0.1.12
oneshot
crates.io
0.1.2-0 up to 0.1.12
0.1.12

History

History
RecordedChangedSources
first indexedGitHub 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.

References

MoveEnter Open