RUSTSEC-2026-0386 `AsyncFd::new` and related constructors violate I/O safety

Not scored Published
Exploited in the wild
Not known
Fix
Available

What is RUSTSEC-2026-0386?

RUSTSEC-2026-0386 is a vulnerability in tokio, published on 13 Oct 2026.

Official description

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.

Which versions are affected by RUSTSEC-2026-0386?

1 open source package ship an affected version, including tokio.

PackageAffectedFixed in
tokio crates.ioFrom 0.3.21.51.6, 1.53.3

How do I fix RUSTSEC-2026-0386?

Upgrade tokio to a fixed version for your release line: 1.51.6 or 1.53.3.

Is RUSTSEC-2026-0386 being exploited?

There is no known exploitation of RUSTSEC-2026-0386 in the wild and no public exploit code.

Sources

Is RUSTSEC-2026-0386 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free