RUSTSEC-2026-0342: Zero-length DATAGRAM frames bypass the receive buffer limit in quinn-proto
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 15/100
Direzione di ricerca
The report describes a vulnerability in the quinn-proto package, fixed in version 0.11.17, and links to the upstream pull request #2790. Start by reviewing that pull request and the RustSec advisory to understand the receive and send buffer accounting flaw. Done means confirming whether this repository is affected and addressing the vulnerable dependency or documenting why it is not applicable.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Zero-length DATAGRAM frames bypass the receive buffer limit in quinn-proto
| Details | |
|---|---|
| Package | quinn-proto |
| Version | 0.11.16 |
| URL | https://github.com/quinn-rs/quinn/pull/2790 |
| Date | 2026-08-17 |
| Patched versions | >=0.11.17 |
| Unaffected versions | <0.5.0 |
quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length
against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the
limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never
triggered eviction and was appended to the queue, which has no other bound.
DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can
therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until
the process is killed. An application that reads incoming datagrams but does so more slowly than
the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints
that do not explicitly set datagram_receive_buffer_size(None) are affected.
The send path had the same accounting flaw: an application could enqueue an unbounded number of
empty outgoing datagrams without ever receiving SendDatagramError::Blocked.
The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both
directions, so that every queued datagram consumes buffer space.
Thanks to @alexpyattaev for reporting this issue.
See advisory page for additional details.
- Lingua principale
- Rust
- Stelle
- 1
- Fork
- 0
- Merge medio
- 1g 15h
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di stackabletech/stackable-odbc-trino
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 62/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 55/100
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authenticationAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 50/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
Tutte le issue di stackabletech/stackable-odbc-trino
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
EmbarkStudios/cargo-deny#910 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
tursodatabase/turso#10054 ·
I maintainer di solito rispondono entro 1 giorno
-
build: Update rust versionForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertadependencies
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
ibm-granite-community/granite-cli#229 ·
I maintainer di solito rispondono entro 1 giorno
-
setTargetAtTime booked ahead of time starts its curve early (values blow up before start_time)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
orottier/web-audio-api-rs#658 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
aosama/astronomical#1318 ·
I maintainer di solito rispondono entro 1 giorno