RUSTSEC-2026-0341: Stream reassembly memory-exhaustion guard in quinn-proto can be bypassed
还没有人认领这个 Issue。
评估
调研方向
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
- 平均合并
- 1 天 15 小时
- 30 天内合并 PR
- 3
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
stackabletech/stackable-odbc-trino 的其他 Issue
-
难度 1/5 1-3 小时 新手友好度 62/100
-
难度 1/5 1 小时以内 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 55/100
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authentication未关闭
难度 2/5 1-3 小时 新手友好度 50/100
-
难度 5/5 一周以上 新手友好度 15/100
查看 stackabletech/stackable-odbc-trino 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
adorsys/status-list-server#698 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
nannou-org/egui_graph#92 ·
维护者通常 1 天内回复
-
documentation good first issue
难度 2/5 半天 新手友好度 72/100
sujithputta02/Esapay#13 ·
-
Deduplicate normalized_f64_bits (hash_table.rs and bloom_filter.rs)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
tursodatabase/turso#10002 ·
维护者通常 1 天内回复
-
needs triage
难度 2/5 1-3 小时 新手友好度 72/100
topgrade-rs/topgrade#2419 ·
维护者通常 1 天内回复