RUSTSEC-2026-0338: Remote peer can panic quinn-proto with zero-length STREAM frames during unordered reads
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 42/100
Piste de recherche
The report describes a panic in quinn-proto’s RangeSet::replace when unordered stream reads receive empty STREAM frames, but it does not identify files or tests in this repository. Start by checking how the ODBC driver uses stackable-odbc-core and whether it uses quinn-proto or unordered reads; the report says ordered reads are unaffected. Done means confirming whether this repository is affected and, if so, addressing the panic and covering the empty-range case.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Remote peer can panic quinn-proto with zero-length STREAM frames during unordered reads
| 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.7.0 |
When a stream is read in unordered mode (for example through RecvStream::read(false) in
quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data
by recording received ranges in a RangeSet through its replace method. When an incoming
STREAM frame carried an empty payload, the Drop implementation of the iterator returned by
replace inserted an empty range into the set, violating the invariant that stored ranges are
non-empty. Subsequent frames overlapping that region then caused a panic while processing the
stream.
A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the
application has put the stream in unordered-read mode. The default ordered read path is not
affected.
The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.
Thanks to Otto Hermann (@ojhermann) 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é 3/5 1-2 jours Accessibilité débutants 55/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
-
sync: small cleanups after #69Ouvertearea::tern-sync kind::cleanup triage::ready
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour
-
review-bot
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
midagedev/bloomery#160 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
oxidecomputer/humility#737 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 65/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
Les mainteneurs répondent en général sous 1 jour