From: Frederic Lecaille Date: Fri, 16 Oct 2026 14:29:36 +0000 (+0200) Subject: BUG/MINOR: quic: valid NEW_TOKEN connections are counted as half-open X-Git-Tag: v3.5-dev10~166 X-Git-Url: https://git.kaiwu.me/$%7BISSUES%7D/static/gitweb.js?a=commitdiff_plain;h=7b37fe84dc95d793ca40c5a5104e9fc1d045f1ca;p=haproxy.git BUG/MINOR: quic: valid NEW_TOKEN connections are counted as half-open Commit 29fb1aee5 ("MINOR: quic-be: QUIC connection allocation adaptation (qc_new_conn())") replaced the token presence check with token_odcid->len when marking a listener connection's peer address as validated. Only Retry token validation populates token_odcid. A connection created with a valid NEW_TOKEN token is therefore counted in half_open_conn and remains subject to the anti-amplification limit until a Handshake packet is successfully processed, even though the token has been accepted. This does not prevent the connection from being established, but the unnecessary anti-amplification limit may delay the handshake. The inflated half_open_conn counter may also reach the Retry threshold earlier, causing more Retry packets to be sent to other clients connecting without a token. Use initial_pkt->token_len instead, as any non-empty token has already been validated by the caller before allocating the connection. This marks the peer address as validated for both accepted token formats without changing the outgoing connection handling. Thank you to Yeonggi Kim for having reported this issue on the haproxy mailing list. Must be backported as far as 3.3. --- diff --git a/src/quic_conn.c b/src/quic_conn.c index a664b9fb1..e992cf91c 100644 --- a/src/quic_conn.c +++ b/src/quic_conn.c @@ -1252,7 +1252,7 @@ struct quic_conn *qc_new_conn(void *target, * already checked token, consider the peer address as validated. */ if (l) { - if (token_odcid->len) { + if (initial_pkt->token_len) { TRACE_STATE("validate peer address due to initial token", QUIC_EV_CONN_INIT, qc); qc->flags |= QUIC_FL_CONN_PEER_VALIDATED_ADDR;