Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add advisory for tokio-rs/tokio#4225 #1106

Merged
merged 5 commits into from Nov 16, 2021
Merged

Add advisory for tokio-rs/tokio#4225 #1106

merged 5 commits into from Nov 16, 2021

Conversation

hawkw
Copy link
Contributor

@hawkw hawkw commented Nov 16, 2021

If a tokio::sync::oneshot channel is closed (via the
oneshot::Receiver::close]method), a data race may occur if the
oneshot::Sender::send method is called while the corresponding
oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves
of the channel can concurrently access a shared memory location, resulting in a
data race. This has been observed to [cause memory corruption][corruption].

Note that the race only occurs when both halves of the channel are used
after one half has called close. Code where close is not used, or where the
Receiver is not awaited and try_recv is not called after calling close,
is not affected.

See tokio-rs/tokio#4225 for more details.

This issue was patched in v1.13.1. The patch was backported to the current
LTS version (v1.8.x) in release v1.8.4.

If a `tokio::sync::oneshot` channel is closed (via the
[`oneshot::Receiver::close`] method), a data race may occur if the
`oneshot::Sender::send` method is called while the corresponding
`oneshot::Receiver` is `await`ed or calling `try_recv`.

When these methods are called concurrently on a closed channel, the two halves
of the channel can concurrently access a shared memory location, resulting in a
data race. This has been observed to [cause memory corruption][corruption].

Note that the race only occurs when **both** halves of the channel are used
after one half has called `close`. Code where `close` is not used, or where the
`Receiver` is not `await`ed and `try_recv` is not called after calling `close`,
is not affected.

See tokio-rs/tokio#4225 for more details.

This issue was patched in v1.13.1. The patch was backported to the current
LTS version (v1.8.x) in release v1.8.4.
@hawkw
Copy link
Contributor Author

hawkw commented Nov 16, 2021

cc @Darksonn

hawkw and others added 2 commits November 16, 2021 13:51
Co-authored-by: Tony Arcieri <bascule@gmail.com>
@Shnatsel Shnatsel merged commit 5f68bba into rustsec:main Nov 16, 2021
@Shnatsel
Copy link
Member

Merged. Thanks a lot for the report!

@hawkw
Copy link
Contributor Author

hawkw commented Nov 16, 2021

No problem!

We may also want to consider an advisory for the tokio-sync crate, which was where this code was originally defined in tokio 0.1.x --- tokio v0.1.14+ just re-exported the oneshot type from tokio-sync. However, that crate was also formerly deprecated two years ago when these APIs were all moved into a single monolithic tokio crate, so I'm not sure if it's strictly necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants