tokio known bugs

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. Note that the race only occurs when both halves of the channel are used after the Receiver 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.

The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`. Thank you to Austin Bonander for finding and reporting this issue.

`tokio::io::ReadHalf<T>::unsplit` can violate the `Pin` contract The soundness issue is described in the [tokio/issues#5372](https://github.com/tokio-rs/tokio/issues/5372) Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf) is unusual, combined with the difficulty of making any arbitrary use-after-free exploitable in Rust without doing a lot of careful alignment of data types in the surrounding code. The `tokio` feature `io-util` is also required to be enabled to trigger this soundness issue. Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e and carllerche appropriately responding and fixing the soundness bug. Tokio before 0.2.0 used `futures` 0.1 that did not have `Pin`, so it is not affected by this issue.

On Windows, configuring a named pipe server with [pipe_mode] will force [ServerOptions]::[reject_remote_clients] as `false`. This drops any intended explicit configuration for the [reject_remote_clients] that may have been set as `true` previously. The default setting of [reject_remote_clients] is normally `true` meaning the default is also overridden as `false`. ## Workarounds Ensure that [pipe_mode] is set first after initializing a [ServerOptions]. For example: ```rust let mut opts = ServerOptions::new(); opts.pipe_mode(PipeMode::Message); opts.reject_remote_clients(true); ``` [ServerOptions]: https://docs.rs/tokio/latest/tokio/net/windows/named_pipe/struct.ServerOptions.html [pipe_mode]: https://docs.rs/tokio/latest/tokio/net/windows/named_pipe/struct.ServerOptions.html#method.pipe_mode [reject_remote_clients]: https://docs.rs/tokio/latest/tokio/net/windows/named_pipe/struct.ServerOptions.html#method.reject_remote_clients

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 the `Receiver` 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#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.close

When aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929

### Impact When configuring a Windows named pipe server, setting `pipe_mode` will reset `reject_remote_clients` to `false`. If the application has previously configured `reject_remote_clients` to `true`, this effectively undoes the configuration. This also applies if `reject_remote_clients` is not explicitly set as this is the default configuration and is cleared by calling `pipe_mode`. Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB). ### Patches The following versions have been patched: * 1.23.1 * 1.20.3 * 1.18.4 The fix will also be present in all releases starting from version 1.24.0. Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected. ### Workarounds Ensure that `pipe_mode` is set **first** after initializing a `ServerOptions`. For example: ```rust let mut opts = ServerOptions::new(); opts.pipe_mode(PipeMode::Message); opts.reject_remote_clients(true); ``` ### References https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients

When aborting a task with JoinHandle::abort, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a LocalSet. This can easily result in race conditions as many projects use Rc or RefCell in their Tokio tasks for better performance.

A race condition could cause a panic when the broadcast channel was dropped with pending receivers. Fixed in 1.38.1.

The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`. Thank you to Austin Bonander for finding and reporting this issue.

`tokio::io::ReadHalf<T>::unsplit` can violate the `Pin` contract The soundness issue is described in the [tokio/issues#5372](https://github.com/tokio-rs/tokio/issues/5372) Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf) is unusual, combined with the difficulty of making any arbitrary use-after-free exploitable in Rust without doing a lot of careful alignment of data types in the surrounding code. The `tokio` feature `io-util` is also required to be enabled to trigger this soundness issue. Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e and carllerche appropriately responding and fixing the soundness bug. Tokio before 0.2.0 used `futures` 0.1 that did not have `Pin`, so it is not affected by this issue.