Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

RUSTSEC-2026-0340: Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#309 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
1/5
Temps estimé
Moins d'une heure
Accessibilité débutants
70/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
networking, security

Piste de recherche

L'avis concerne le crate quinn-proto, commencez donc par vérifier s'il apparaît dans Cargo.lock (par exemple avec cargo tree -i quinn-proto). Si c'est le cas, exécutez cargo update -p quinn-proto pour passer à la version 0.11.18 ou ultérieure, puis confirmez avec cargo tree et lancez la suite de tests. La tâche est terminée lorsque le lockfile se résout vers une version corrigée et que la compilation et les tests réussissent toujours.

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.17
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
2
Forks
2
Merge moyen
2 j 21 h
PR mergées (30 j)
6

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de DiamondLightSource/numtracker

Toutes les issues de DiamondLightSource/numtracker

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.