quinn-proto

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.

The limit on memory used to buffer outgoing datagrams, introduced in 0.11.17, subtracted an evicted datagram's size from the buffered byte counter twice when Datagrams::send was called with drop = true (as Connection::send_datagram in the quinn crate does) while the buffer was full. Under sustained eviction the counter drifts below its true value: debug builds panic with an integer underflow, while release builds wrap the counter, drain the whole queue, and then panic on a desynchronization check in a later send call. In quinn, this panic occurs while the connection lock is held, poisoning it and causing a double panic (and thus an abort) when the connection is dropped.

This can be triggered without a malicious peer, by an application that sends a burst of datagrams and then idles. It can also be triggered by a peer that keeps the connection alive with PING frames while withholding acknowledgements, so that the sender's congestion window stays closed and the outgoing queue never drains. Applications that use send_datagram_wait are not affected.

Only 0.11.17 is affected; the flaw was corrected in 0.11.18 by removing the redundant subtraction.

Thanks to @alexpyattaev for reporting and @vcarus for fixing this issue.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

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.

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program

When a stream is read in unordered mode (for example through RecvStream::read(false) in quinn-proto or read_unordered in quinn), quinn-proto proactively deduplicates received data by recording received ranges in a RangeSet through its replace method. When an incoming STREAM frame carried an empty payload, the Drop implementation of the iterator returned by replace inserted an empty range into the set, violating the invariant that stored ranges are non-empty. Subsequent frames overlapping that region then caused a panic while processing the stream.

A remote peer can trigger this with five small STREAM frames (two of them zero-length) once the application has put the stream in unordered-read mode. The default ordered read path is not affected.

The flaw was corrected in 0.11.18 by ignoring empty ranges in RangeSet::replace.

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

quinn-proto bounds its queue of received datagrams by charging each queued frame's payload length against TransportConfig::datagram_receive_buffer_size, evicting the oldest datagrams when the limit is exceeded. A DATAGRAM frame with an empty payload was charged zero bytes, so it never triggered eviction and was appended to the queue, which has no other bound.

DATAGRAM frames are not subject to flow control. A peer that has completed the handshake can therefore send a stream of empty DATAGRAM frames and grow the receiver's heap without limit until the process is killed. An application that reads incoming datagrams but does so more slowly than the peer sends them is still affected. Receiving datagrams is enabled by default, so all endpoints that do not explicitly set datagram_receive_buffer_size(None) are affected.

The send path had the same accounting flaw: an application could enqueue an unbounded number of empty outgoing datagrams without ever receiving SendDatagramError::Blocked.

The flaw was corrected in 0.11.17 by accounting for the fixed per-datagram overhead in both directions, so that every queued datagram consumes buffer space.

Thanks to @alexpyattaev for reporting this issue.

When processing a NEW_CONNECTION_ID frame, quinn-proto queues a RETIRE_CONNECTION_ID frame for each connection ID that the peer asked it to retire. The normal path bounds this queue and closes the connection with a CONNECTION_ID_LIMIT_ERROR if the bound would be exceeded. However, the path handling a connection ID that had already been retired pushed onto the queue without applying the limit and without deduplicating.

A peer that has completed the handshake can first send a NEW_CONNECTION_ID frame with a large retire_prior_to value to advance the receiver's connection ID window, and then repeatedly send NEW_CONNECTION_ID frames with sequence numbers below that window. Each such frame adds another entry to the queue. The queue is only drained by sending RETIRE_CONNECTION_ID frames, which are subject to congestion control, so a peer that withholds acknowledgements can stall the drain while continuing to flood, growing the victim's memory use without bound.

The flaw was corrected in 0.11.17 by applying the same limit on the already-retired path.

Thanks to @scadastrangelove for reporting this issue.

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.

Summary

A remote, unauthenticated attacker can trigger a denial of service in applications using vulnerable quinn versions by sending a crafted QUIC Initial packet containing malformed quic_transport_parameters. In quinn-proto parsing logic, attacker-controlled varints are decoded with unwrap(), so truncated encodings cause Err(UnexpectedEnd) and panic. This is reachable over the network with a single packet and no prior trust or authentication.

Details

The issue is panic-on-untrusted-input in QUIC transport parameter parsing. In quinn-proto (observed in quinn-proto 0.11.13), parsing of some transport parameters uses a fallible varint decode followed by unwrap(). For malformed/truncated parameter values, decode returns UnexpectedEnd, and unwrap() panics.

Observed output:

thread 'tokio-rt-worker' (2366474) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

PoC

Reproduces against the upstream Quinn server example.

1. Start server:

cargo run --example server -- ./

2. Prepare PoC client environment:

python3 -m venv .venv
source .venv/bin/activate
pip install aioquic

3. Run PoC script attack.py against server QUIC listener (default example target shown):

python attack.py

Observed output

thread 'tokio-rt-worker' (2366903) panicked at quinn-proto/src/transport_parameters.rs:473:67:
called `Result::unwrap()` on an `Err` value: UnexpectedEnd

Impact

Vulnerability type: Remote Denial of Service (panic/crash) Attack requirements: Network reachability to UDP QUIC listener Authentication/privileges: None Who is impacted: Any server/application using affected quinn/quinn-proto versions where this parse path is reachable; process-level impact depends on integration panic handling policy

This vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program