quinn-proto 一天公告六則遠端 DoS，最小的觸發只要五個 QUIC 封包
RustSec · 2026-10-12
Rust QUIC 協定實作 quinn-proto 在同一天被 RustSec 掛上六則弱點公告，編號 RUSTSEC-2026-0338 到 RUSTSEC-2026-0343。共同點是遠端對等端不需認證，就能讓你的 QUIC 端點 panic 或吃光記憶體。其中三則在 RustSec 套件索引頁標為 HIGH。
這六則的發布日都是 2026-10-12。我們實際讀完全文的是 0338 與 0340，其餘四則只讀到套件索引頁上的一行摘要，細節以下文標註為準。
六則公告一覽
| 編號 | 問題（依索引頁摘要） | 索引頁嚴重度 |
|---|---|---|
RUSTSEC-2026-0338 | unordered 讀取模式下，零長度 STREAM frame 可使程式 panic | 未標示 |
RUSTSEC-2026-0339 | 待處理的 connection ID 退役項目無上限成長 | 未標示 |
RUSTSEC-2026-0340 | 對等端的最小 ACK 延遲在啟用 ACK_FREQUENCY 時可使程式 panic | HIGH |
RUSTSEC-2026-0341 | 繞過 stream 重組的記憶體耗盡防護 | HIGH |
RUSTSEC-2026-0342 | 零長度 DATAGRAM frame 繞過接收緩衝上限 | 未標示 |
RUSTSEC-2026-0343 | datagram 傳送緩衝的計帳錯誤可使傳送端 panic | HIGH |
同一個套件今年已有前科：索引頁還列著 2026-06-22 的 RUSTSEC-2026-0185（無上限的亂序 stream 重組導致記憶體耗盡）與 2026-03-09 的 RUSTSEC-2026-0037。0341 就是繞過這類防護的新手法。
漏洞機制：兩個讀過全文的例子
0338 是不變量被空區間破壞。應用程式啟用 unordered 讀取後，quinn-proto 用 RangeSet 記錄已收到的資料範圍來去重。若 STREAM frame 的 payload 是空的，iterator 的 Drop 實作仍會插入一個空區間，違反「集合內區間皆非空」的假設，之後重疊的 frame 就會 panic。公告指出，遠端只要送五個小型 STREAM frame、其中兩個零長度即可觸發。預設的 ordered 讀取不受影響。
0340 是標準庫 Duration::clamp 的前置條件被對等端打破。啟用 ACK_FREQUENCY 傳送（TransportConfig::ack_frequency_config(Some(..))）時，AckFrequencyState::candidate_max_ack_delay 會用對等端宣告的最小 ACK 延遲當下界。公告舉的例子：對等端宣告最小延遲 100 ms、最大延遲 100 ms，RTT 為 5 ms 時，clamp 的下界變成 100 ms、上界卻只有 25 ms，下界大於上界便 panic。這組參數能通過 transport parameter 的驗證。公告給的 CVSS 3.1 為 7.5，向量 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H，只影響可用性。
// before：下界可能大於上界，clamp 直接 panic
delay.clamp(peer_min, upper)
// after（0.11.18）：以明確的 min / max 邊界計算上面是示意，不是原始 diff。兩個例子的共通模式是：協定欄位通過了格式檢查，卻違反內部函式的前置條件，而 Rust 在這種情況下選擇 panic，於是遠端輸入直接變成程序崩潰。
受影響版本與觸發條件
- 0338：公告列出修補版本
>=0.11.18，僅在應用程式啟用 unordered 讀取時受影響。 - 0340：修補版本同為
>=0.11.18，<0.11.0不受影響；僅在啟用 ACK_FREQUENCY 傳送（預設關閉）時受影響。 - 0339、0341、0342、0343：本文未讀到內文，修補版本請直接查各公告頁，不要假設與 0338 相同。
0338 與 0340 的公告都引用了 quinn-rs/quinn 的 PR #2868 作為修補。兩則的 GHSA 分別為 GHSA-465w-v9q3-7j98 與 GHSA-3g6h-r5qx-f6hq，公告皆未列 CVE。
影響範圍與該檢查什麼
直接依賴 quinn 或 quinn-proto 的服務都要查：自架的 QUIC 伺服器、HTTP/3 閘道，以及透過其他 crate 間接引入它的專案。用 cargo tree -i quinn-proto 能看出誰把它拉進來。
不同設定的暴露面不同：沒開 unordered 讀取與 ACK_FREQUENCY 的服務，不會踩到 0338 與 0340，但記憶體類與 datagram 類問題與這些選項無關的部分，需逐則確認。另一個實務重點是這些 panic 在每條連線的驅動路徑上發生，若你的程式沒有隔離連線任務，單一惡意對等端就可能拖垮整個程序。
修補與緩解
升級到 quinn-proto 的 0.11.18 或更新版本，是 0338 與 0340 公告明列的修補。0338 的修法是讓 RangeSet::replace 忽略空區間；0340 的修法是改用明確的最小、最大邊界計算延遲。公告未提供不升級的緩解方式，只有「不啟用相關選項」可降低 0338、0340 的暴露，這不能取代升級。
公告頁未載明 0338 的 CVSS 分數，也未提供其他四則的修補細節，本文不補完。
原始來源：RUSTSEC-2026-0338、RUSTSEC-2026-0340、RustSec quinn-proto 索引