{"id":"GHSA-3g6h-r5qx-f6hq","aliases":["RUSTSEC-2026-0340"],"status":"published","title":"Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled","description":"When sending ACK_FREQUENCY frames is enabled through\n`TransportConfig::ack_frequency_config(Some(..))`, the peer's transport parameters could cause\n`AckFrequencyState::candidate_max_ack_delay` to call `Duration::clamp` with a minimum greater\nthan its maximum, which panics.\n\nFor example, a peer advertising a `min_ack_delay` of 100,000 microseconds and a `max_ack_delay`\nof 100 milliseconds passes transport parameter validation. At a 5 ms RTT, the lower bound of the\nclamp becomes 100 ms while the upper bound is 25 ms, violating the precondition of `clamp` and\npanicking while driving the connection. Both automatically derived and explicitly configured\nmaximum ACK delays use this calculation.\n\nSending ACK_FREQUENCY frames is disabled by default, so only endpoints that opt in are affected.\n\nThe flaw was corrected in 0.11.18 by computing the delay with explicit minimum and maximum bounds\ninstead of `clamp`.\n\nThanks to [@zerox80](https://github.com/zerox80) for reporting this issue.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","from":"osv"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"published":"2026-09-14T12:00:00Z","modified":"2026-10-12T18:15:01Z","fixes":[{"ecosystem":"crates.io","package":"quinn-proto","fixed_in":["0.11.18"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"crates.io","package":"quinn-proto","ranges":[{"type":"SEMVER","events":[{"introduced":"0.11.0"},{"fixed":"0.11.18"}]}]}],"references":[{"url":"https://crates.io/crates/quinn-proto","tags":["package"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2026-0340.html","tags":["advisory"]},{"url":"https://github.com/quinn-rs/quinn/pull/2868","tags":["web"]}],"sources":{"osv":[{"id":"RUSTSEC-2026-0340","title":"Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled","description":"When sending ACK_FREQUENCY frames is enabled through\n`TransportConfig::ack_frequency_config(Some(..))`, the peer's transport parameters could cause\n`AckFrequencyState::candidate_max_ack_delay` to call `Duration::clamp` with a minimum greater\nthan its maximum, which panics.\n\nFor example, a peer advertising a `min_ack_delay` of 100,000 microseconds and a `max_ack_delay`\nof 100 milliseconds passes transport parameter validation. At a 5 ms RTT, the lower bound of the\nclamp becomes 100 ms while the upper bound is 25 ms, violating the precondition of `clamp` and\npanicking while driving the connection. Both automatically derived and explicitly configured\nmaximum ACK delays use this calculation.\n\nSending ACK_FREQUENCY frames is disabled by default, so only endpoints that opt in are affected.\n\nThe flaw was corrected in 0.11.18 by computing the delay with explicit minimum and maximum bounds\ninstead of `clamp`.\n\nThanks to [@zerox80](https://github.com/zerox80) for reporting this issue.","status":"published","published":"2026-09-14T12:00:00Z","modified":"2026-10-12T18:15:01.975478256Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:40.430679Z"}]}}