RUSTSEC-2026-0384: Race condition in `tokio::time::Interval` on Tokio v1.54.0
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 1/5
- Geschätzter Aufwand
- Unter einer Stunde
- Anfängerfreundlichkeit
- 20/100
Rechercherichtung
The issue reports a Tokio vulnerability and links to its fix at tokio-rs/tokio#8692, but it does not identify a change needed in numtracker. First check the project's Tokio dependency and whether it can use a patched version (>=1.54.1); done means numtracker no longer depends on the affected 1.54.0 release.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Race condition in
tokio::time::Intervalon Tokio v1.54.0
| Details | |
|---|---|
| Package | tokio |
| Version | 1.54.0 |
| URL | https://github.com/tokio-rs/tokio/pull/8692 |
| Date | 2026-10-21 |
| Patched versions | >=1.54.1 |
| Unaffected versions | <1.54.0 |
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 and carabistouille for reporting this privately using the procedure outlined in our security policy. They both reported the issue independently of each other.
See advisory page for additional details.
- Vorherrschende Sprache
- Rust
- Sterne
- 2
- Forks
- 2
- Ø Merge
- 13 Std. 13 Min.
- Gemergte PRs (30 T.)
- 5
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Kein Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus DiamondLightSource/numtracker
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 70/100
DiamondLightSource/numtracker#309 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
DiamondLightSource/numtracker#278 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 45/100
DiamondLightSource/numtracker#329 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 20/100
DiamondLightSource/numtracker#325 ·
-
RUSTSEC-2026-0387: Multiple timing variability issues in operations intended to be constant-timeOffen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 1/100
DiamondLightSource/numtracker#324 ·
Alle Issues in DiamondLightSource/numtracker
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
max-sixty/worktrunk#4727 · 7 Kommentare · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
follow-up
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
carrick-sh/carrick#1859 ·
Maintainer antworten meist innerhalb von 1 Tag
-
crate: spate-kafka documentation priority: medium
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
Maintainer antworten meist innerhalb von 1 Tag