Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

RUSTSEC-2026-0340: Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled

オープン 初心者向け
#309 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
1/5
見積もり時間
1時間未満
初心者へのやさしさ
70/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust

調査の方向性

このアドバイザリは quinn-proto クレートに関するものなので、まず Cargo.lock に含まれているかを確認してください(例: cargo tree -i quinn-proto)。含まれている場合は、cargo update -p quinn-proto を実行して 0.11.18 以降に更新し、cargo tree で確認してからテストスイートを実行してください。lockfile が修正済みバージョンに解決され、ビルドとテストが引き続き成功していれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled

Details
Package quinn-proto
Version 0.11.17
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.

主要言語
Rust
スター
1
フォーク
2
平均マージ
14日 15時間
マージ済み PR(30日)
1

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DiamondLightSource/numtracker のほかの issue

DiamondLightSource/numtracker の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。