Most recent entries from all

CVE-2026-25800 — quinn-proto has remote memory exhaustion from unbounded out-of-order stream reassembly

2026-10-13T01:59:57.441802+00:00

Affected: quinn-rs quinn

Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. Starting in version 0.1.0 and prior to version 0.11.15, the `Assembler` component that assembles unordered stream fragments into consecutive chunks of the stream incurs some overhead for non-contiguous fragments. Readers that read from a `RecvStream` in order (through an `AsyncRead` impl for example) will be sensitive to peers that send fragments while leaving out early parts of the stream, and in particular, fragments with many gaps (because these cannot be defragmented). In such a scenario, the receiving connection suffers from high buffer overhead, enabling memory exhaustion. Version 0.11.15 fixes the issue.

GHSA-4w2j-m93h-cj5j — Quinn: Remote memory exhaustion in quinn-proto from unbounded out-of-order stream reassembly

2026-10-13T01:59:57.441851+00:00

Affected: crates.io: quinn-proto

## Summary

The `Assembler` component that assembles unordered stream fragments into consecutive chunks of the stream incurs some overhead for non-contiguous fragments. Readers that read from a `RecvStream` in order (through an `AsyncRead` impl for example) will be sensitive to peers that send fragments while leaving out early parts of the stream, and in particular, fragments with many gaps (because these cannot be defragmented). In such a scenario, the receiving connection suffers from high buffer overhead, enabling memory exhaustion.

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

2026-10-13T01:59:57.441877+00:00

Affected: crates.io: quinn-proto

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](https://github.com/ojherm…