RUSTSEC-2026-0343: Outgoing datagram buffer accounting can panic the sender in quinn-proto

Ouverte
  • Quelque chose ne va pas ?
#308 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
Moins d'une heure
Accessibilité débutants
15/100
Type d'issue
Bug
Clarté
À clarifier
Activité
Active
Stack technique
rust
Domaine
networking

Piste de recherche

The payload names no files in this repository. Start by checking whether Cargo.lock resolves quinn-proto to 0.11.17, which the advisory says is the only affected version, and whether any Cargo.toml depends on it directly or through quinn. Done means the lockfile resolves quinn-proto at 0.11.18 or later and the project's tests still pass. Confirm with a maintainer that this is the intended fix before starting.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Outgoing datagram buffer accounting can panic the sender in quinn-proto

Details
Package quinn-proto
Version 0.11.17
URL https://github.com/quinn-rs/quinn/pull/2806
Date 2026-09-14
Patched versions >=0.11.18
Unaffected versions <0.11.17

The limit on memory used to buffer outgoing datagrams, introduced in 0.11.17, subtracted an
evicted datagram's size from the buffered byte counter twice when Datagrams::send was called
with drop = true (as Connection::send_datagram in the quinn crate does) while the buffer was
full. Under sustained eviction the counter drifts below its true value: debug builds panic with an
integer underflow, while release builds wrap the counter, drain the whole queue, and then panic on
a desynchronization check in a later send call. In quinn, this panic occurs while the
connection lock is held, poisoning it and causing a double panic (and thus an abort) when the
connection is dropped.

This can be triggered without a malicious peer, by an application that sends a burst of datagrams
and then idles. It can also be triggered by a peer that keeps the connection alive with PING frames
while withholding acknowledgements, so that the sender's congestion window stays closed and the
outgoing queue never drains. Applications that use send_datagram_wait are not affected.

Only 0.11.17 is affected; the flaw was corrected in 0.11.18 by removing the redundant subtraction.

Thanks to @alexpyattaev for reporting and
@vcarus for fixing this issue.

See advisory page for additional details.

Langage dominant
Rust
Étoiles
2
Forks
2
Merge moyen
13 h 13 min
PR mergées (30 j)
5

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.