- Reported
-
- Issued
-
- Package
-
quinn-proto
(crates.io)
- Type
-
Vulnerability
- Categories
-
- Keywords
-
#panic
- Aliases
-
- References
-
- CVSS Score
- 7.5
HIGH
- CVSS Details
-
- Attack Vector
- Network
- Attack Complexity
- Low
- Privileges Required
- None
- User Interaction
- None
- Scope
- Unchanged
- Confidentiality Impact
- None
- Integrity Impact
- None
- Availability Impact
- High
- CVSS Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Patched
-
- Unaffected
-
Description
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.
Advisory available under CC0-1.0
license.