CVE-2026-115567 in Tokio
Summary
by MITRE • 10/23/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Tokio runtime for Rust applications experienced a critical race condition vulnerability in version 1.54.0 that compromised the integrity of its internal timer management system. The flaw originated from an asynchronous interaction between the tokio::time::Interval::poll_tick function, which is commonly invoked via .tick().await syntax, and the multi-threaded runtime's time driver thread. In a multi-threaded environment, Tokio relies on precise synchronization to manage scheduled tasks and timers across different threads. However, in this specific version, there was an insufficient synchronization mechanism when handling timer entries during their expiration or cancellation phases. This lack of proper locking allowed a scenario where the main application logic could drop an internal timer entry while the time driver thread was simultaneously attempting to fire it.
This race condition resulted in a use-after-free vulnerability within safe Rust code, which is particularly concerning because it bypasses many of the memory safety guarantees that Rust typically provides through its ownership model. When the timer entry was dropped without coordinating with the firing thread, references to the timer's waker and associated task state remained valid from the perspective of one part of the system while being deallocated or invalidated by another. This discrepancy led to undefined behavior manifesting as assertion panics, which could cause application crashes during development or testing phases where assertions are enabled. More severely, it resulted in task reference-count corruption, potentially leading to memory leaks if references were not properly decremented or premature termination of tasks if counts dropped incorrectly.
The most critical impact stems from the heap memory corruption caused by accessing freed memory through dangling pointers associated with the waker and task state structures. Heap corruption can lead to unpredictable application behavior, data integrity issues, and potentially exploitable conditions depending on how the corrupted memory is subsequently used. Although Tokio operates in safe Rust, which generally prevents direct pointer manipulation errors, complex asynchronous patterns involving shared mutable state across threads can still trigger these low-level memory safety violations if synchronization primitives are not correctly applied. The vulnerability effectively undermined the reliability of scheduled tasks and interval-based operations within applications relying on this version of the runtime for time-sensitive logic such as heartbeats, retries, or periodic data processing.
This issue is classified under CWE-362 which covers concurrent execution using shared resources with improper synchronization, specifically highlighting the race condition aspect that allows multiple threads to access shared data simultaneously without proper coordination. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this vulnerability relates to T1059 Command and Scripting Interpreter if an attacker could leverage the memory corruption for code execution, although in practice it primarily affects availability through crashes or stability degradation rather than direct exploitation for remote code execution unless combined with other vulnerabilities. The impact is predominantly on service reliability and data consistency within long-running Tokio-based services such as web servers, database proxies, or microservices that depend heavily on precise timing mechanisms.
The vulnerability was addressed in version 1.54.1 of the Tokio runtime through improved synchronization logic between the poll_tick mechanism and the time driver thread. Developers using affected versions should upgrade to 1.54.1 or later immediately to restore proper memory safety guarantees for timer operations. For applications that cannot update immediately, mitigating strategies include avoiding complex interval-based scheduling patterns in multi-threaded contexts where possible, implementing external synchronization layers around critical timing logic, and enabling comprehensive logging and monitoring to detect assertion panics early before they escalate into more severe stability issues. Regular dependency audits using tools like cargo-audit are recommended to ensure timely identification of such runtime vulnerabilities in the Rust ecosystem.