UnsoundRUSTSEC-2026-0386 · tokio
RUSTSEC-2026-0386: `AsyncFd::new` and related constructors violate I/O safety
Short answertokio has an API that can cause undefined behaviour from safe code: `AsyncFd::new` and related constructors violate I/O safety. Fixed in 1.51.6, 1.53.3.
| Crate | tokio |
|---|---|
| Type | Unsound (memory-corruption) |
| Affected versions | From 0.3.2 before 1.51.6; from 1.52.0 before 1.53.3. |
| Fixed in | 1.51.6, 1.53.3 |
| Severity | not scored |
| Published | 2026-10-13 |
| Last changed | 2026-10-23 |
| Also known as | none |
| Affected functions | tokio::io::unix::AsyncFd::new, tokio::io::unix::AsyncFd::try_new, tokio::io::unix::AsyncFd::try_with_interest, tokio::io::unix::AsyncFd::with_interest |
What to do
- See which version you have:
cargo tree -i tokio(it also shows which of your dependencies pulls it in). - Update within your version requirement:
cargo update -p tokio. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for exampletokio = "1.53.3") or update the dependency that pulls it in. - Check again with
cargo audit, or paste your Cargo.lock into our Cargo.toml checker.
Details from the advisory
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<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. 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 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.
References
- Package: crates.io/crates/tokio
- Advisory: rustsec.org/advisories/RUSTSEC-2026-0386.html
- Web: github.com/tokio-rs/tokio/pull/8587
- Report: github.com/tokio-rs/tokio/issues/8538
- Report: github.com/tokio-rs/tokio/issues/8539
From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.
Other advisories for tokio
- VulnerabilityRUSTSEC-2021-0072 · 2021-07-07Task dropped in wrong thread when aborting `LocalSet` task
- VulnerabilityRUSTSEC-2021-0124 · 2021-11-16Data race when sending and receiving after closing a `oneshot` channel
- VulnerabilityRUSTSEC-2023-0001 · 2023-01-04reject_remote_clients Configuration corruption
- UnsoundRUSTSEC-2023-0005 · 2023-01-11`tokio::io::ReadHalf<T>::unsplit` is Unsound
- UnsoundRUSTSEC-2025-0023 · 2025-04-07Broadcast channel calls clone in parallel, but does not require `Sync`
- VulnerabilityRUSTSEC-2026-0384 · 2026-10-21Race condition in `tokio::time::Interval` on Tokio v1.54.0
Up next
Same cratetokio: security historyEvery advisory for this crate, and whether it is safe to use today.Read it next →Did this answer your question?