Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
On the multi-threaded runtime, there is a race condition between Interval::polltick and the runtime's time driver. This affects Interval only. Sleep and Timeout are not affected. Details In Tokio v1.54.0, a race condition between tokio::time::Interval::polltick (including .tick().await) and the runtime time driver can drop an internal timer entry without synchronizing with the driver thread that is firing it. This causes a data race and use-after-free on the timer's waker and task state in safe Rust, leading to assertion panics, task reference-count corruption, or heap memory corruption. This bug was introduced by https://github.com/tokio-rs/tokio/pull/8458, and it was fixed by https://github.com/tokio-rs/tokio/pull/8692. Impact This may lead to crashes and use-after-frees in applications using Interval on a multi-threaded runtime. Since this issue is known to lead to crashes in production systems, the v1.54.0 release of Tokio has been yanked. Credits Thank you to creepycode…
Recommended action: Upgrade to 1.54.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
crates.io tokio >= 0.3.2, < 1.51.6; >= 1.52.0, < 1.53.3
Fixed in
1.51.61.53.3· Vendor fix available
Issue
`tokio::io::unix::AsyncFd` provides safe constructors (`new`, `with_interest`, `try_new`, and `try_with_interest`) that accept any `T: AsRawFd` rather than requiring proof of ownership or validity of the file descriptor. Because `RawFd` implements `AsRawFd`, safe code can construct an `AsyncFd` from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the `AsyncFd` is still alive. This violates I/O safety in two ways: 1. `AsyncFd ` implements `AsFd` for all `T: AsRawFd` by calling `BorrowedFd::borrow_raw(self.as_raw_fd())`, allowing safe code to obtain an arbitrary `BorrowedFd ` without owning the file descriptor. 2. Tokio's I/O driver stores a pointer to an internal allocation in the `epoll`/`kqueue` user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an `AsyncFd` is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the…
Recommended action: Upgrade to 1.53.3 or 1.51.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.44.2, 1.43.1 or 1.38.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
tokio::io::ReadHalf<T::unsplit can violate the Pin contract The soundness issue is described in the 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.
Recommended action: Upgrade to 1.24.2, 1.20.4 or 1.18.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When configuring a Windows named pipe server, setting pipemode will reset rejectremoteclients to false. If the application has previously configured rejectremoteclients to true, this effectively undoes the configuration. This also applies if rejectremoteclients is not explicitly set as this is the default configuration and is cleared by calling pipemode. 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 pipemode is set first after initializing a ServerOptions. For example: References https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#piperejectremoteclients
Recommended action: Upgrade to 1.23.1, 1.20.3 or 1.18.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
crates.io tokio >= 1.9.0, < 1.13.1; >= 0.1.14, < 1.8.4
Fixed in
1.8.41.13.1· Vendor fix available
Issue
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 tryrecv. 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 tryrecv is not called after calling close, is not affected.
Recommended action: Upgrade to 1.13.1 or 1.8.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.8.1, 1.7.2, 1.6.3 or 1.5.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.