https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 25 Oct 2026 20:43:10 +0000 https://db.gcve.eu/vuln/cve-2026-115567 <p><strong>Affected:</strong> tokio-rs tokio</p> <p>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&#39;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&#39;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.</p> <p><strong>Affected:</strong> tokio-rs tokio</p> <p>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&#39;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&#39;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.</p> https://db.gcve.eu/vuln/cve-2026-115567 https://db.gcve.eu/vuln/rustsec-2026-0384 <p><strong>Affected:</strong> crates.io: tokio</p> <p>## Summary</p> <p>On the multi-threaded runtime, there is a race condition between `Interval::poll_tick` and the runtime&#39;s time driver.</p> <p>This affects `Interval` only. `Sleep` and `Timeout` are **not** affected.</p> <p>## Details</p> <p>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&#39;s waker and task state in safe Rust, leading to assertion panics, task reference-count corruption, or heap memory corruption.</p> <p>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.</p> <p>## Impact</p> <p>This may lead to crashes and use-after-frees in applications using `Interval` on a multi-threaded runtime.</p> <p>Since this issue is known to lead to crashes in production systems, the v1.54.0 release of Tokio has been yanked.</p> <p>## Credits</p> <p>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.</p> <p><strong>Affected:</strong> crates.io: tokio</p> <p>## Summary</p> <p>On the multi-threaded runtime, there is a race condition between `Interval::poll_tick` and the runtime&#39;s time driver.</p> <p>This affects `Interval` only. `Sleep` and `Timeout` are **not** affected.</p> <p>## Details</p> <p>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&#39;s waker and task state in safe Rust, leading to assertion panics, task reference-count corruption, or heap memory corruption.</p> <p>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.</p> <p>## Impact</p> <p>This may lead to crashes and use-after-frees in applications using `Interval` on a multi-threaded runtime.</p> <p>Since this issue is known to lead to crashes in production systems, the v1.54.0 release of Tokio has been yanked.</p> <p>## Credits</p> <p>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.</p> https://db.gcve.eu/vuln/rustsec-2026-0384