Skip to content
Heist/ feed
Back to feed
HighFix available

Peer minimum ACK delay can panic quinn-proto when ACK_FREQUENCY transmission is enabled

Type: advisorySources: OSV

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 source

Published 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"
}