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

RUSTSEC-2026-0341: Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed

オープン
#14 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
30/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust
領域
security

調査の方向性

The advisory identifies the affected component as quinn-proto's stream Assembler and links to the fix in quinn-rs/quinn pull request 2790; this issue names no repository files or tests. Read that change and the RUSTSEC-2026-0185 fix to understand the guard and its bypass. Done means the chunk cap is checked after every insert, including unordered deduplication, and excessive chunks are compacted or rejected as described.

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

説明

Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed

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.11.15

The fix for RUSTSEC-2026-0185 in 0.11.15 added a cap on the number of chunks buffered by the
Assembler that reassembles out-of-order stream data. However, the cap was only checked inside
the branch that triggers defragmentation, which only runs when the estimated over-allocation
exceeds a threshold proportional to the amount of buffered data. Frames handled entirely by the
unordered-read deduplication loop returned before the check ran at all.

A peer sending one small gapped STREAM frame per packet (for example, 6-byte frames separated by
1-byte gaps) keeps the per-chunk overhead below the defragmentation threshold, so the cap is never
evaluated and the chunk count grows until stream-level flow control stops the peer. With the default
TransportConfig (100 concurrent unidirectional streams and a 1.25 MB stream receive window), a
remote, unauthenticated peer can pin roughly 3 GB of receiver memory using about 125 MB of accounted
stream data. The memory is not reclaimed until the affected streams or the connection are closed.

The flaw was corrected in 0.11.17 by checking the chunk count after every insert (including in the
unordered deduplication loop) and compacting the buffer once it passes a watermark above the cap.
A stream is rejected once compaction can no longer bring the chunk count back under the cap.

Versions before 0.11.15 are affected by the original, broader issue described in RUSTSEC-2026-0185.

Thanks to Otto Hermann (@ojhermann) for reporting and fixing
this issue.

See advisory page for additional details.

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

環境構築

はじめの一歩

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

stackabletech/stackable-odbc-trino のほかの issue

stackabletech/stackable-odbc-trino の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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