Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled
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](https://github.com/zerox80) for reporting this issue.
- Products
- quinn-proto
- Affected versions
- Not specified
- Fixed versions
- 0.11.18
- CVEs
- Not specified
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 30 Oct 2026, 08:44 UTC · Revision 1
Source evidence
Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled
core-osv · Original sourcePublished 14 Sept 2026, 12:00 UTC
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](https://github.com/zerox80) for reporting this issue.
osv:RUSTSEC-2026-0340
quinn-proto
Fixed versions: 0.11.18
Complete source record
{
"id": "e45c08c7794201218b3830e28019adff8720924011227ba301e7785b66e56ac7",
"url": "https://osv.dev/vulnerability/RUSTSEC-2026-0340",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled",
"summary": "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](https://github.com/zerox80) for reporting this issue.",
"evidence": "osv:RUSTSEC-2026-0340",
"products": [
{
"name": {
"value": "quinn-proto",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "0.11.18",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "RUSTSEC-2026-0340",
"aliases": [
"GHSA-3g6h-r5qx-f6hq",
"RUSTSEC-2026-0340"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
}
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0.11.0"
},
{
"fixed": "0.11.18"
}
]
}
],
"package": {
"name": "quinn-proto",
"purl": "pkg:cargo/quinn-proto",
"ecosystem": "crates.io"
},
"database_specific": {
"cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"source": "https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0340.json",
"categories": [
"denial-of-service"
],
"informational": null
},
"ecosystem_specific": {
"affects": {
"os": [],
"arch": [],
"functions": []
},
"affected_functions": null
}
}
],
"modified": "2026-10-12T18:15:01.975478256Z",
"provider": "osv",
"references": [
"https://crates.io/crates/quinn-proto",
"https://rustsec.org/advisories/RUSTSEC-2026-0340.html",
"https://github.com/quinn-rs/quinn/pull/2868"
],
"provider_metadata": {
"license": "CC0-1.0"
}
},
"related_cves": [],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 306474,
"published_at": "2026-09-14T12:00:00+00:00"
}