RUSTSEC-2026-0340: Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Rust
- Estrellas
- 1
- Forks
- 0
- Merge medio
- 1 d 15 h
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de stackabletech/stackable-odbc-trino
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 62/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 55/100
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authenticationAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 50/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
Todos los issues de stackabletech/stackable-odbc-trino
Issues similares
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authenticationAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 60/100
-
core: Amount::from_str panics on values above 21M BTC instead of returning an errorPosiblemente ocupada @bhuvan-somisetty la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
crate: spate-s3
Dificultad 2/5 Medio día Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
write_iceberg ignores the table's write.parquet.compression-codec propertyPosiblemente ocupada @YuangGao la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Eventual-Inc/Daft#7606 ·
Los mantenedores suelen responder en 1 día
-
review-bot
Dificultad 2/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día