Tokio: Race condition in `tokio::time::Interval`

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

23 Oct 2026 17:13:16 UTC

Source modified

23 Oct 2026 17:13:16 UTC

Observed here

23 Oct 2026 18:48:20 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 5.8 CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

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.

Source published

23 Oct 2026 18:17:21 UTC

Source modified

23 Oct 2026 19:42:24 UTC

Observed here

25 Oct 2026 05:17:25 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 5.8 CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

### 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.

Source published

23 Oct 2026 20:54:00 UTC

Source modified

23 Oct 2026 21:10:33 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V4 · CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

Publisher rating · MODERATE

## 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.

Source published

21 Oct 2026 12:00:00 UTC

Source modified

24 Oct 2026 08:30:13 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.