RUSTSEC-2026-0340: Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 55/100
Direção de pesquisa
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.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Rust
- Estrelas
- 2
- Forks
- 0
- Merge médio
- 1d 5h
- PRs com merge (30d)
- 4
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de stackabletech/stackable-odbc-trino
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 15/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
Todas as issues de stackabletech/stackable-odbc-trino
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
longbridge/nsh#804 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
Mantenedores costumam responder em até 1 dia
-
devex good first issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
calcit-lang/calcit#2538 ·
Mantenedores costumam responder em até 1 dia