RUSTSEC-2026-0340: Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 55/100
Piste de recherche
The advisory identifies AckFrequencyState::candidate_max_ack_delay and TransportConfig::ack_frequency_config, but gives no file or test path in this repository. First check how this project depends on and configures quinn-proto, then trace whether it enables ACK_FREQUENCY transmission. Done means the affected dependency behavior is addressed and a regression check covers peer minimum ACK delay exceeding the RTT-based maximum.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled
| Details | |
|---|---|
| Package | quinn-proto |
| Version | 0.11.16 |
| URL | https://github.com/quinn-rs/quinn/pull/2868 |
| Date | 2026-09-14 |
| Patched versions | >=0.11.18 |
| Unaffected versions | <0.11.0 |
When sending ACK_FREQUENCY frames is enabled through
TransportConfig::ack_frequency_config(Some(..)), the peer's transport parameters could cause
AckFrequencyState::candidate_max_ack_delay to call Duration::clamp with a minimum greater
than its maximum, which panics.
For example, a peer advertising a min_ack_delay of 100,000 microseconds and a max_ack_delay
of 100 milliseconds passes transport parameter validation. At a 5 ms RTT, the lower bound of the
clamp becomes 100 ms while the upper bound is 25 ms, violating the precondition of clamp and
panicking while driving the connection. Both automatically derived and explicitly configured
maximum ACK delays use this calculation.
Sending ACK_FREQUENCY frames is disabled by default, so only endpoints that opt in are affected.
The flaw was corrected in 0.11.18 by computing the delay with explicit minimum and maximum bounds
instead of clamp.
Thanks to @zerox80 for reporting this issue.
See advisory page for additional details.
- Langage dominant
- Rust
- Étoiles
- 1
- Forks
- 0
- Merge moyen
- 11 h 44 min
- PR mergées (30 j)
- 2
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de stackabletech/stackable-odbc-trino
-
Difficulté 4/5 3-5 jours Accessibilité débutants 42/100
-
RUSTSEC-2026-0342: Zero-length DATAGRAM frames bypass the receive buffer limit in quinn-protoOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 15/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 20/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 30/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 55/100
Toutes les issues de stackabletech/stackable-odbc-trino
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
storytold/photocraft#5710 ·
Les mainteneurs répondent en général sous 1 jour
-
Two tests fail on a Windows checkout: a CRLF parse in feature_walk_tests, an 8.3 TEMP path in libraries_testsPeut-être pris @CamWight l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
bherbruck/solvecraft#1186 · 1 commentaire ·
-
area: screenshot audit bug good first issue priority: P3 security severity: info type: correctness
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
pierruno-labs/prowl#31 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
limitlessprojects/Go-Hybrid#50 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Les mainteneurs répondent en général sous 1 jour