tokio

An event-driven, non-blocking I/O platform for writing asynchronous I/O backed applications.

View on Cargo

Activity

Latest release: 1w ago
Total releases: 201
Cadence: ~5 days
Last 12 months: 24

Reach

Downloads: 1059.6M

Details

License: MIT
First release: Jul 01, 2016

Releases

Version	Released
`1.54.1` patch	Oct 21, 2026
`1.54.0` minor 1 CVE	Oct 19, 2026
`1.53.3` patch	Oct 13, 2026
`1.51.6` patch	Oct 13, 2026
`1.53.2` patch 1 CVE	Oct 03, 2026
`1.51.5` patch 1 CVE	Oct 03, 2026
`1.53.1` unknown 1 CVE	Jul 20, 2026
`1.53.0` unknown 1 CVE	Jul 17, 2026
`1.52.4` unknown 1 CVE	Jul 16, 2026
`1.51.4` unknown 1 CVE	Jul 16, 2026
`1.52.3` unknown 1 CVE	May 08, 2026
`1.51.3` unknown 1 CVE	May 08, 2026
`1.47.5` unknown 1 CVE	May 07, 2026
`1.52.2` unknown 1 CVE	May 04, 2026
`1.51.2` unknown 1 CVE	May 04, 2026
`1.52.1` unknown 1 CVE	Apr 16, 2026
`1.52.0` unknown 1 CVE	Apr 14, 2026
`1.51.1` unknown 1 CVE	Apr 08, 2026
`1.51.0` unknown 1 CVE	Apr 03, 2026
`1.47.4` unknown 1 CVE	Apr 02, 2026
`1.50.0` unknown 1 CVE	Mar 03, 2026
`1.49.0` unknown 1 CVE	Jan 03, 2026
`1.47.3` unknown 1 CVE	Jan 02, 2026
`1.43.4` unknown 1 CVE	Jan 02, 2026
`1.47.2` unknown 1 CVE	Oct 14, 2025
`1.43.3` unknown 1 CVE	Oct 14, 2025
`1.48.0` unknown 1 CVE	Oct 14, 2025
`1.47.1` unknown 1 CVE	Aug 01, 2025
`1.43.2` unknown 1 CVE	Aug 01, 2025
`1.47.0` unknown 1 CVE	Jul 26, 2025
`1.46.1` unknown 1 CVE	Jul 04, 2025
`1.46.0` unknown 1 CVE	Jul 02, 2025
`1.45.1` unknown 1 CVE	May 24, 2025
`1.45.0` unknown 1 CVE	May 06, 2025
`1.42.1` unknown 2 CVEs	Apr 08, 2025
`1.44.2` unknown 1 CVE	Apr 05, 2025
`1.43.1` unknown 1 CVE	Apr 04, 2025
`1.38.2` unknown 1 CVE	Apr 03, 2025
`1.44.1` unknown 2 CVEs	Mar 13, 2025
`1.44.0` unknown 2 CVEs	Mar 07, 2025
`1.43.0` unknown 2 CVEs	Jan 08, 2025
`1.42.0` unknown 2 CVEs	Dec 03, 2024
`1.41.1` unknown 2 CVEs	Nov 07, 2024
`1.41.0` unknown 2 CVEs	Oct 22, 2024
`1.40.0` unknown 2 CVEs	Aug 30, 2024
`1.39.3` unknown 2 CVEs	Aug 17, 2024
`1.39.2` unknown 2 CVEs	Jul 27, 2024
`1.39.1` unknown 2 CVEs	Jul 23, 2024
`1.39.0` unknown yanked 2 CVEs	Jul 23, 2024
`1.38.1` unknown 2 CVEs	Jul 16, 2024

1–50 of 201

Dependencies (32)

Depends on

1.54.1

Used by

84293

Supply-chain exposure

84,293 tracked projects depend on this, 1.0% of every package we track.

A known CVE here directly exposes every one of them.

Known CVEs (7)

CVE-2026-115567 GHSA-5wjr-9356-4wc8 RUSTSEC-2026-0384 Oct 23, 2026

Tokio: Race condition in `tokio::time::Interval`

Medium
Local High Low None

Summary

On the multi-threaded runtime, there is a race condition between Interval::poll_tick 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::poll_tick (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 and carabistouille for reporting this privately using the procedure outlined in our security policy. They both reported the issue independently of each other.

Affected versions

1.54.0

Fixed in

1.54.1

References

https://github.com/tokio-rs/tokio/security/advisories/GHSA-5wjr-9356-4wc8
https://nvd.nist.gov/vuln/detail/CVE-2026-115567
https://github.com/tokio-rs/tokio/pull/8458
https://github.com/tokio-rs/tokio/pull/8692
https://github.com/tokio-rs/tokio/commit/2b4eba7833864c04ecd2f3e5f4a97ff4f6fa28d0
https://github.com/tokio-rs/tokio/commit/5ed619bbaba87357ee5103d71b75e7c84cad99c9

Updated Oct 23, 2026 · Source: OSV.dev
RUSTSEC-2026-0386 Oct 13, 2026

`AsyncFd::new` and related constructors violate I/O safety

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:

AsyncFd<T> 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.

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 first AsyncFd deregisters the reused file descriptor number and frees the first while the original file description remains registered in epoll, leading to a use-after-free when a readiness event fires.

Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, AsyncFd::new, AsyncFd::with_interest, AsyncFd::try_new, and AsyncFd::try_with_interest are deprecated in favor of the unsafe constructors AsyncFd::register and AsyncFd::register_with_interest. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the AsyncFd.

Fixed in

1.51.61.53.3

References

https://crates.io/crates/tokio
https://rustsec.org/advisories/RUSTSEC-2026-0386.html
https://github.com/tokio-rs/tokio/pull/8587
https://github.com/tokio-rs/tokio/issues/8538
https://github.com/tokio-rs/tokio/issues/8539

Updated Oct 23, 2026 · Source: OSV.dev
GHSA-rr8g-9fpq-6wmg RUSTSEC-2025-0023 Apr 07, 2025

Tokio broadcast channel calls clone in parallel, but does not require `Sync`

Low
Network Low None None

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.

Fixed in

1.38.21.43.11.44.2

References

https://github.com/tokio-rs/tokio/pull/7232
https://github.com/tokio-rs/tokio
https://rustsec.org/advisories/RUSTSEC-2025-0023.html

Updated Sep 10, 2026 · Source: OSV.dev
GHSA-4q83-7cq4-p6wg RUSTSEC-2023-0005 Feb 04, 2023

`tokio::io::ReadHalf<T>::unsplit` is Unsound

Low

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.

Fixed in

1.18.51.20.41.24.2

References

https://github.com/tokio-rs/tokio/issues/5372
https://github.com/tokio-rs/tokio
https://rustsec.org/advisories/RUSTSEC-2023-0005.html

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-22466 GHSA-7rrj-xr53-82p7 RUSTSEC-2023-0001 Jan 06, 2023

Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe

5.4 / 10
Medium
Network Low Low None Unchanged Low None Low

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:

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

Fixed in

1.18.41.20.31.23.1

References

https://github.com/tokio-rs/tokio/security/advisories/GHSA-7rrj-xr53-82p7
https://nvd.nist.gov/vuln/detail/CVE-2023-22466
https://github.com/tokio-rs/tokio/pull/5336
https://github.com/tokio-rs/tokio
https://github.com/tokio-rs/tokio/releases/tag/tokio-1.23.1
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2021-45710 GHSA-fg7r-2g4j-5cgr RUSTSEC-2021-0124 Jan 06, 2022

Race Condition in tokio

8.1 / 10
High
Network High None None Unchanged High High High

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.

Fixed in

1.8.41.13.1

References

https://nvd.nist.gov/vuln/detail/CVE-2021-45710
https://github.com/tokio-rs/tokio/issues/4225
https://github.com/tokio-rs/tokio
https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/tokio/RUSTSEC-2021-0124.md
https://rustsec.org/advisories/RUSTSEC-2021-0124.html

Updated Nov 08, 2023 · Source: OSV.dev
CVE-2021-38191 GHSA-2grh-hm3w-w7hv RUSTSEC-2021-0072 Aug 25, 2021

Race condition in tokio

5.9 / 10
Medium
Network High None None Unchanged None None High

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.

Fixed in

1.5.11.6.31.7.21.8.1

References

https://nvd.nist.gov/vuln/detail/CVE-2021-38191
https://github.com/tokio-rs/tokio/issues/3929
https://github.com/tokio-rs/tokio
https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/tokio/RUSTSEC-2021-0072.md
https://rustsec.org/advisories/RUSTSEC-2021-0072.html

Updated Nov 08, 2023 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

minor 1
patch 5
unknown 195

201 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More