Skip to content

Update Rust crate tokio to v1.51.6 [SECURITY] - #1051

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/crate-tokio-vulnerability
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/crate-tokio-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Feb 9, 2024 •

Copy link
Copy Markdown
Contributor

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Type Update Change
tokio (source) dependencies minor 1.13.0 → 1.51.6
tokio (source) dev-dependencies minor 1.13.0 → 1.51.6

Race Condition in tokio

CVE-2021-45710 / GHSA-fg7r-2g4j-5cgr

More information

Details

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.

Severity

  • CVSS Score: 8.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


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

CVE-2023-22466 / GHSA-7rrj-xr53-82p7

More information

Details

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

Severity

  • CVSS Score: 5.4 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


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

GHSA-4q83-7cq4-p6wg

More information

Details

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.

Severity

Low

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


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

GHSA-rr8g-9fpq-6wmg

More information

Details

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.

Severity

  • CVSS Score: 2.7 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Race Condition in tokio

CVE-2021-45710 / GHSA-fg7r-2g4j-5cgr / RUSTSEC-2021-0124

More information

Details

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.

Severity

  • CVSS Score: 8.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Data race when sending and receiving after closing a oneshot channel

CVE-2021-45710 / GHSA-fg7r-2g4j-5cgr / RUSTSEC-2021-0124

More information

Details

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.

See tokio#4225 for more details.

Severity

Unknown

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).


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

CVE-2023-22466 / GHSA-7rrj-xr53-82p7 / RUSTSEC-2023-0001

More information

Details

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

Severity

  • CVSS Score: 5.4 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


reject_remote_clients Configuration corruption

CVE-2023-22466 / GHSA-7rrj-xr53-82p7 / RUSTSEC-2023-0001

More information

Details

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:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);

Severity

Unknown

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).


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

GHSA-4q83-7cq4-p6wg / RUSTSEC-2023-0005

More information

Details

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.

Severity

Low

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


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

GHSA-4q83-7cq4-p6wg / RUSTSEC-2023-0005

More information

Details

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.

Severity

Unknown

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).


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

GHSA-rr8g-9fpq-6wmg / RUSTSEC-2025-0023

More information

Details

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.

Severity

  • CVSS Score: 2.7 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Broadcast channel calls clone in parallel, but does not require Sync

GHSA-rr8g-9fpq-6wmg / RUSTSEC-2025-0023

More information

Details

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.

Severity

Unknown

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).


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

RUSTSEC-2026-0386

More information

Details

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.

Severity

Unknown

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).


Release Notes

tokio-rs/tokio (tokio)

v1.51.6: Tokio v1.51.6

Compare Source

1.51.6 (October 13th, 2026)

Added
  • io: add AsyncFd::register and AsyncFd::register_with_interest (#​8587)
Changed
  • io: deprecate AsyncFd::{new, with_interest, try_new, try_with_interest} (#​8587)
Fixed
  • io: wake and drop DuplexStream wakers outside the lock (#​8618)
  • macros: avoid unreachable_code in join! and try_join! for Infallible (#​8518)
  • runtime: fix paused time auto-advancing when I/O wakes a task on current_thread (#​8595)
  • sync: wake waiters outside the lock when closing a semaphore (#​8529)
  • test: fix several flaky tests (#​8196, #​8427, #​8609)

v1.51.5: Tokio v1.51.5

Compare Source

1.51.5 (October 3rd, 2026)

Fixed
  • fs: handle integer overflow in buffered relative seek (#​8574)
  • io: revert "always cleanup AsyncFd registration list on deregister" (#​8540)
  • process: unregister Windows wait before closing child handle (#​8564)
  • rt: drop blocking pool mutex before shutting down rejected task (#​8562)
  • sync: fix mpsc index wraparound in block reclamation (#​8546)
  • sync: forget mpsc Permit before sending value (#​8560)
  • sync: validate MAX_PERMITS in Semaphore::acquire (#​8548)
  • sync: wake broadcast Sender::closed outside mutex (#​8558)
  • task: drop replaced waker outside lock in JoinSet (#​8554)
  • time: drop timer lock before dropping waker in clear_entry (#​8552)
  • time: expire timers directly on shutdown without rotating wheel (#​8570)
Fixed (unstable)
  • rt: ignore current_thread task dumps from other runtimes (#​8544)
  • rt: preserve io_uring context if a completion waker panics (#​8566)
  • sync: fix semaphore use-after-free and permit leak on tracing panic (#​8542)
  • time: drop stored waker when cancelling alt timer entry (#​8550)

v1.51.4: Tokio v1.51.4

Compare Source

1.51.4 (July 16th, 2026)

Fixed
  • runtime: don't skip the driver when before_park schedules work (#​8222)

v1.51.3: Tokio v1.51.3

Compare Source

1.51.3 (May 8th, 2026)

Fixed
  • sync: fix underflow in mpsc channel len() (#​8062)
  • sync: notify receivers in mpsc OwnedPermit::release() method (#​8075)
  • sync: require that an RwLock has max_readers != 0 (#​8076)
  • sync: return Empty from try_recv() when mpsc is closed with outstanding permits (#​8074)

v1.51.2: Tokio v1.51.1

Compare Source

1.51.2 (May 4th, 2026)

This release reverts the LIFO slot stealing change introduced in 1.51.0 (#​7431), due to its performance impact. (#​8100)

v1.51.1: Tokio v1.51.1

Compare Source

1.51.1 (April 8th, 2026)

Fixed
  • sync: fix semaphore reopens after forget (#​8021)
  • net: surface errors from SO_ERROR on recv for UDP sockets on Linux (#​8001)
Fixed (unstable)
  • metrics: fix worker_local_schedule_count test (#​8008)
  • rt: do not leak fd when cancelling io_uring open operation (#​7983)

v1.51.0: Tokio v1.51.0

Compare Source

1.51.0 (April 3rd, 2026)

Added
  • net: implement get_peer_cred on Hurd (#​7989)
  • runtime: add tokio::runtime::worker_index() (#​7921)
  • runtime: add runtime name (#​7924)
  • runtime: stabilize LocalRuntime (#​7557)
  • wasm: add wasm32-wasip2 networking support (#​7933)
Changed
  • runtime: steal tasks from the LIFO slot (#​7431)
Fixed
  • docs: do not show "Available on non-loom only." doc label (#​7977)
  • macros: improve overall macro hygiene (#​7997)
  • sync: fix notify_waiters priority in Notify (#​7996)
  • sync: fix panic in Chan::recv_many when called with non-empty vector on closed channel (#​7991)

v1.50.0: Tokio v1.50.0

Compare Source

1.50.0 (Mar 3rd, 2026)

Added
  • net: add TcpStream::set_zero_linger (#​7837)
  • rt: add is_rt_shutdown_err (#​7771)
Changed
  • io: add optimizer hint that memchr returns in-bounds pointer (#​7792)
  • io: implement vectored writes for write_buf (#​7871)
  • runtime: panic when event_interval is set to 0 (#​7838)
  • runtime: shorten default thread name to fit in Linux limit (#​7880)
  • signal: remember the result of SetConsoleCtrlHandler (#​7833)
  • signal: specialize windows Registry (#​7885)
Fixed
  • io: always cleanup AsyncFd registration list on deregister (#​7773)
  • macros: remove (most) local use declarations in tokio::select! (#​7929)
  • net: fix GET_BUF_SIZE constant for target_os = "android" (#​7889)
  • runtime: avoid redundant unpark in current_thread scheduler (#​7834)
  • runtime: don't park in current_thread if before_park defers waker (#​7835)
  • io: fix write readiness on ESP32 on short writes (#​7872)
  • runtime: wake deferred tasks before entering block_in_place (#​7879)
  • sync: drop rx waker when oneshot receiver is dropped (#​7886)
  • runtime: fix double increment of num_idle_threads on shutdown (#​7910, #​7918, #​7922)
Unstable
  • fs: check for io-uring opcode support (#​7815)
  • runtime: avoid lock acquisition after uring init (#​7850)
Documented
  • docs: update outdated unstable features section (#​7839)
  • io: clarify the behavior of AsyncWriteExt::shutdown() (#​7908)
  • io: explain how to flush stdout/stderr (#​7904)
  • io: fix incorrect and confusing AsyncWrite documentation (#​7875)
  • rt: clarify the documentation of Runtime::spawn (#​7803)
  • rt: fix missing quotation in docs (#​7925)
  • runtime: correct the default thread name in docs (#​7896)
  • runtime: fix event_interval doc (#​7932)
  • sync: clarify RwLock fairness documentation (#​7919)
  • sync: clarify that recv returns None once closed and no more messages (#​7920)
  • task: clarify when to use spawn_blocking vs dedicated threads (#​7923)
  • task: doc that task drops before JoinHandle completion (#​7825)
  • signal: guarantee that listeners never return None (#​7869)
  • task: fix task module feature flags in docs (#​7891)
  • task: fix two typos (#​7913)
  • task: improve the docs of Builder::spawn_local (#​7828)
  • time: add docs about auto-advance and when to use sleep (#​7858)
  • util: fix typo in docs (#​7926)

v1.49.0: Tokio v1.49.0

Compare Source

1.49.0 (January 3rd, 2026)

Added
  • net: add support for TCLASS option on IPv6 (#​7781)
  • runtime: stabilize runtime::id::Id (#​7125)
  • task: implement Extend for JoinSet (#​7195)
  • task: stabilize the LocalSet::id() (#​7776)
Changed
  • net: deprecate {TcpStream,TcpSocket}::set_linger (#​7752)
Fixed
  • macros: fix the hygiene issue of join! and try_join! (#​7766)
  • runtime: revert "replace manual vtable definitions with Wake" (#​7699)
  • sync: return TryRecvError::Disconnected from Receiver::try_recv after Receiver::close (#​7686)
  • task: remove unnecessary trait bounds on the Debug implementation (#​7720)
Unstable
  • fs: handle EINTR in fs::write for io-uring (#​7786)
  • fs: support io-uring with tokio::fs::read (#​7696)
  • runtime: disable io-uring on EPERM (#​7724)
  • time: add alternative timer for better multicore scalability (#​7467)
Documented
  • docs: fix a typos in bounded.rs and park.rs (#​7817)
  • io: add SyncIoBridge cross-references to copy and copy_buf (#​7798)
  • io: doc that AsyncWrite does not inherit from std::io::Write (#​7705)
  • metrics: clarify that num_alive_tasks is not strongly consistent (#​7614)
  • net: clarify the cancellation safety of the TcpStream::peek (#​7305)
  • net: clarify the drop behavior of unix::OwnedWriteHalf (#​7742)
  • net: clarify the platform-dependent backlog in TcpSocket docs (#​7738)
  • runtime: mention LocalRuntime in new_current_thread docs (#​7820)
  • sync: add missing period to mpsc::Sender::try_send docs (#​7721)
  • sync: clarify the cancellation safety of oneshot::Receiver (#​7780)
  • sync: improve the docs for the errors of mpsc (#​7722)
  • task: add example for spawn_local usage on local runtime (#​7689)

v1.48.0: Tokio v1.48.0

Compare Source

1.48.0 (October 14th, 2025)

The MSRV is increased to 1.71.

Added
  • fs: add File::max_buf_size (#​7594)
  • io: export Chain of AsyncReadExt::chain (#​7599)
  • net: add SocketAddr::as_abstract_name (#​7491)
  • net: add TcpStream::quickack and TcpStream::set_quickack (#​7490)
  • net: implement AsRef<Self> for TcpStream and UnixStream (#​7573)
  • task: add LocalKey::try_get (#​7666)
  • task: implement Ord for task::Id (#​7530)
Changed
  • deps: bump windows-sys to version 0.61 (#​7645)
  • fs: preserve max_buf_size when cloning a File (#​7593)
  • macros: suppress clippy::unwrap_in_result in #[tokio::main] (#​7651)
  • net: remove PollEvented noise from Debug formats (#​7675)
  • process: upgrade Command::spawn_with to use FnOnce (#​7511)
  • sync: remove inner mutex in SetOnce (#​7554)
  • sync: use UnsafeCell::get_mut in Mutex::get_mut and RwLock::get_mut (#​7569)
  • time: reduce the generated code size of Timeout<T>::poll (#​7535)
Fixed
  • macros: fix hygiene issue in join! and try_join! (#​7638)
  • net: fix copy/paste errors in udp peek methods (#​7604)
  • process: fix error when runtime is shut down on nightly-2025-10-12 (#​7672)
  • runtime: use release ordering in wake_by_ref() even if already woken (#​7622)
  • sync: close the broadcast::Sender in broadcast::Sender::new() (#​7629)
  • sync: fix implementation of unused RwLock::try_* methods (#​7587)
Unstable
  • tokio: use cargo features instead of --cfg flags for taskdump and io_uring (#​7655, #​7621)
  • fs: support io_uring in fs::write (#​7567)
  • fs: support io_uring with File::open() (#​7617)
  • fs: support io_uring with OpenOptions (#​7321)
  • macros: add local runtime flavor (#​7375, #​7597)
Documented
  • io: clarify the zero capacity case of AsyncRead::poll_read (#​7580)
  • io: fix typos in the docs of AsyncFd readiness guards (#​7583)
  • net: clarify socket gets closed on drop (#​7526)
  • net: clarify the behavior of UCred::pid() on Cygwin (#​7611)
  • net: clarify the supported platform of set_reuseport() and reuseport() (#​7628)
  • net: qualify that SO_REUSEADDR is only set on Unix (#​7533)
  • runtime: add guide for choosing between runtime types (#​7635)
  • runtime: clarify the behavior of Handle::block_on (#​7665)
  • runtime: clarify the edge case of Builder::global_queue_interval() (#​7605)
  • sync: clarify bounded channel panic behavior (#​7641)
  • sync: clarify the behavior of tokio::sync::watch::Receiver (#​7584)
  • sync: document cancel safety on SetOnce::wait (#​7506)
  • sync: fix the docs of parking_lot feature flag (#​7663)
  • sync: improve the docs of UnboundedSender::send (#​7661)
  • sync: improve the docs of sync::watch (#​7601)
  • sync: reword allocation failure paragraph in broadcast docs (#​7595)
  • task: clarify the behavior of several spawn_local methods (#​7669)
  • task: clarify the task ID reuse guarantees (#​7577)
  • task: improve the example of poll_proceed (#​7586)

v1.47.5: Tokio v1.47.5

Compare Source

1.47.5 (May 7th, 2026)

Fixed
  • sync: fix underflow in mpsc channel len() (#​8062)
  • sync: notify receivers in mpsc OwnedPermit::release() method (#​8075)
  • sync: require that an RwLock has max_readers != 0 (#​8076)
  • sync: return Empty from try_recv() when mpsc is closed with outstanding permits (#​8074)

v1.47.4: Tokio v1.47.4

Compare Source

1.47.4 (April 2nd, 2026)

Fixed
  • sync: fix panic in Chan::recv_many when called with non-empty vector on closed channel (#​7991)

v1.47.3

Compare Source

v1.47.2

Compare Source

v1.47.1: Tokio v1.47.1

Compare Source

1.47.1 (August 1st, 2025)

Fixed
  • process: fix panic from spurious pidfd wakeup (#​7494)
  • sync: fix broken link of Python asyncio.Event in SetOnce docs (#​7485)

v1.47.0: Tokio v1.47.0

Compare Source

1.47.0 (July 25th, 2025)

This release adds poll_proceed and cooperative to the coop module for
cooperative scheduling, adds SetOnce to the sync module which provides
similar functionality to [std::sync::OnceLock], and adds a new method
sync::Notify::notified_owned() which returns an OwnedNotified without
a lifetime parameter.

Added

  • coop: add cooperative and poll_proceed (#​7405)
  • sync: add SetOnce (#​7418)
  • sync: add sync::Notify::notified_owned() (#​7465)

Changed

  • deps: upgrade windows-sys 0.52 → 0.59 ([#​7117])
  • deps: update to socket2 v0.6 ([#​7443])
  • sync: improve AtomicWaker::wake performance (#​7450)

Documented

  • metrics: fix listed feature requirements for some metrics (#​7449)
  • runtime: improve safety comments of Readiness<'_> (#​7415)

v1.46.1: Tokio v1.46.1

Compare Source

1.46.1 (July 4th, 2025)

This release fixes incorrect spawn locations in runtime task hooks for tasks spawned using tokio::spawn rather than Runtime::spawn. This issue only effected the spawn location in TaskMeta::spawned_at, and did not effect task locations in Tracing events.

Unstable

  • runtime: add TaskMeta::spawn_location tracking where a task was spawned (#​7440)

v1.46.0: Tokio v1.46.0

Compare Source

1.46.0 (July 2nd, 2025)

Fixed
  • net: fixed TcpStream::shutdown incorrectly returning an error on macOS (#​7290)

Added

  • sync: mpsc::OwnedPermit::{same_channel, same_channel_as_sender} methods ([#​7389])
  • macros: biased option for join! and try_join!, similar to select! (#​7307)
  • net: support for cygwin ([#​7393])
  • net: support pope::OpenOptions::read_write on Android ([#​7426])
  • net: add Clone implementation for net::unix::SocketAddr ([#​7422])

Changed

  • runtime: eliminate unnecessary lfence while operating on queue::Local<T> (#​7340)
  • task: disallow blocking in LocalSet::{poll,drop} ([#​7372])

Unstable

  • runtime: add TaskMeta::spawn_location tracking where a task was spawned ([#​7417])
  • runtime: removed borrow from LocalOptions parameter to runtime::Builder::build_local ([#​7346])

Documented

  • io: clarify behavior of seeking when start_seek is not used ([#​7366])
  • io: document cancellation safety of AsyncWriteExt::flush ([#​7364])
  • net: fix docs for recv_buffer_size method (#​7336)
  • net: fix broken link of RawFd in TcpSocket docs ([#​7416])
  • net: update AsRawFd doc link to current Rust stdlib location ([#​7429])
  • readme: fix double period in reactor description ([#​7363])
  • runtime: add doc note that on_*_task_poll is unstable (#​7311)
  • sync: update broadcast docs on allocation failure ([#​7352])
  • time: add a missing panic scenario of time::advance ([#​7394])

[!IMPORTANT]
✂ PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 4827dba to 391b8ba Compare February 12, 2024 18:11
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 391b8ba to fc584ca Compare March 28, 2024 17:58
@renovate renovate Bot changed the title fix(deps): update rust crate tokio to v1.36.0 [security] fix(deps): update rust crate tokio to v1.37.0 [security] Mar 28, 2024
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from fc584ca to 3894130 Compare March 29, 2024 16:22
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 3894130 to 62a7eb8 Compare May 30, 2024 23:08
@renovate renovate Bot changed the title fix(deps): update rust crate tokio to v1.37.0 [security] fix(deps): update rust crate tokio to v1.38.0 [security] May 30, 2024
@renovate renovate Bot changed the title fix(deps): update rust crate tokio to v1.38.0 [security] fix(deps): update rust crate tokio to v1.18.5 [security] Jun 17, 2024
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 62a7eb8 to 2e2cd81 Compare February 22, 2025 08:40
@renovate renovate Bot changed the title fix(deps): update rust crate tokio to v1.18.5 [security] fix(deps): update rust crate tokio to v1.13.1 [security] Feb 22, 2025
@renovate renovate Bot changed the title fix(deps): update rust crate tokio to v1.13.1 [security] fix(deps): update rust crate tokio to v1.18.5 [security] Feb 22, 2025
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 2e2cd81 to 1e51dfc Compare April 7, 2025 18:27
@renovate renovate Bot changed the title fix(deps): update rust crate tokio to v1.18.5 [security] fix(deps): update rust crate tokio to v1.38.2 [security] Apr 7, 2025
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 1e51dfc to 5e0e16b Compare August 10, 2025 15:53
@renovate renovate Bot changed the title fix(deps): update rust crate tokio to v1.38.2 [security] chore(deps): update rust crate tokio to v1.38.2 [security] Sep 25, 2025
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch 2 times, most recently from edc9d44 to 4b6f691 Compare December 11, 2025 15:04
@renovate renovate Bot changed the title chore(deps): update rust crate tokio to v1.38.2 [security] chore(deps): update rust crate tokio to v1.13.1 [security] Dec 11, 2025
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 4b6f691 to 0d2878a Compare December 11, 2025 21:27
@renovate renovate Bot changed the title chore(deps): update rust crate tokio to v1.13.1 [security] chore(deps): update rust crate tokio to v1.38.2 [security] Dec 11, 2025
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 0d2878a to a64eb22 Compare December 31, 2025 18:46
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from a64eb22 to 794ddbc Compare February 2, 2026 16:16
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 794ddbc to 9d095ba Compare February 12, 2026 13:33
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 9d095ba to 84d686f Compare February 25, 2026 17:53
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 84d686f to a6ca7bf Compare March 13, 2026 13:13
@renovate renovate Bot changed the title chore(deps): update rust crate tokio to v1.38.2 [security] Update Rust crate tokio to v1.38.2 [SECURITY] Apr 8, 2026
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from a6ca7bf to 3ff444f Compare May 18, 2026 13:55
@renovate renovate Bot changed the title Update Rust crate tokio to v1.38.2 [SECURITY] Update Rust crate tokio to v1.13.1 [SECURITY] Jun 20, 2026
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch 2 times, most recently from 47ada1a to 31b6139 Compare June 20, 2026 06:53
@renovate renovate Bot changed the title Update Rust crate tokio to v1.13.1 [SECURITY] Update Rust crate tokio to v1.38.2 [SECURITY] Jun 20, 2026
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 31b6139 to 4df5b56 Compare July 21, 2026 00:33
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 4df5b56 to 84e4ff5 Compare August 12, 2026 02:48
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 84e4ff5 to a554e7f Compare September 25, 2026 00:20
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from a554e7f to 65dc801 Compare October 13, 2026 13:50
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 65dc801 to 6555c27 Compare October 20, 2026 15:35
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@renovate
renovate Bot force-pushed the renovate/crate-tokio-vulnerability branch from 6555c27 to 321a080 Compare October 23, 2026 18:17
@renovate renovate Bot changed the title Update Rust crate tokio to v1.38.2 [SECURITY] Update Rust crate tokio to v1.51.6 [SECURITY] Oct 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants