Tokio CVE-2026-115567

Requires all of: Tokio exactly at version 1.54.0, the multi-threaded runtime flavor (the current-thread runtime is not implicated), and application use of tokio::time::Interval via poll_tick or .tick().await. Sleep and Timeout are explicitly unaffected. The flaw manifests only within a narrow, timing-dependent race window between Interval polling and the time driver firing the entry (reflected by AC:H/AT:P), and it arises from the application's own concurrent timer usage rather than attacker-controlled input, which strongly limits realistic adversarial exploitation. Limiting factors: single affected version (now yanked), multi-threaded-runtime-only, Interval-only, and no required/available remote vector.

This is a memory-safety/reliability defect (CWE-362 race condition leading to use-after-free), not a conventional remotely-weaponizable vulnerability. The CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:L/UI:N) is self-consistent and points to LOW real-world attack risk: exploitation is local, requires a high-complexity timing window and a specific attack requirement (AT:P), and the dominant impact is availability (VA:H - crashes/panics) with only limited integrity impact (VI:L) and no confidentiality impact (VC:N). Critically, the condition is triggered by the application's own normal concurrent use of tokio::time::Interval on a multi-threaded runtime rather than by attacker-supplied input, so the 'attacker' model is weak - this behaves far more like a correctness/stability bug than a targeted exploit primitive. No EPSS score, KEV listing, or working PoC is present in the input; the only references are the vendor advisory, fix PRs/commits, and the 1.54.1 release, i.e. remediation artifacts, not exploit code. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a moderate-priority correctness fix. Signals are internally consistent - there is no CVSS-vs-description conflict here - but note the raw 5.8 score overstates adversarial threat; the practical urgency is driven by production crash risk, not exploitability.

On a multi-threaded Tokio runtime, an application that polls a tokio::time::Interval races with the runtime's time driver as a timer fires, dropping the timer entry without synchronizing with the firing driver thread. This produces a use-after-free on the waker and task state, surfacing as an assertion panic, task reference-count corruption, or heap corruption that crashes the service. No public exploit was identified at time of analysis; the issue is primarily self-inflicted through ordinary Interval usage rather than attacker-driven, and the trigger depends on an inherently narrow timing window (AC:H/AT:P).