https://db.gcve.eu/rss/recent/all/10 Most recent entries from all 2026-10-25T20:43:10.519630+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent entries. https://db.gcve.eu/vuln/cve-2026-115567 CVE-2026-115567 — Tokio: Race condition in `tokio::time::Interval` 2026-10-25T20:43:10.521361+00:00

Affected: tokio-rs tokio

Tokio is a runtime for writing applications with Rust. In 1.54.0, a race condition between tokio::time::Interval::poll_tick (including .tick().await) and the multi-threaded runtime's time driver could drop an internal timer entry without synchronizing with the driver thread that was firing it. The race caused a use-after-free on the timer's waker and task state in safe Rust, which could produce assertion panics, task reference-count corruption, or heap memory corruption. This issue is fixed in 1.54.1.

 https://db.gcve.eu/vuln/rustsec-2026-0384 RUSTSEC-2026-0384 — Race condition in `tokio::time::Interval` on Tokio v1.54.0 2026-10-25T20:43:10.521460+00:00

Affected: crates.io: tokio

## 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](https://github.com/ByteZ1337) and [carabistouille](https://github.com/carabistouflette) for reporting this privately using the procedure outlined in our security policy. They both reported the issue independently of each other.