Fix path validation deadlock after peer address verification - #523
Open
aswanthk777 wants to merge 1 commit into
Open
Fix path validation deadlock after peer address verification#523aswanthk777 wants to merge 1 commit into
aswanthk777 wants to merge 1 commit into
Conversation
The server-side anti-amplification helpers (inc/dec/cmp_anti_ampl_limit) all stop applying the limit once verified_peer_address is set: the limit value is frozen from that point on. need_send_validation_frames and need_expand_padding_frames, however, kept consulting the frozen value. For a path opened by a small packet — exactly what a NAT rebinding looks like to a server — the sequence deadlocks: 1. The first packet on the new 4-tuple is small (e.g. a bare PING), so the path starts with anti_ampl_limit of only a few hundred bytes. 2. The server sends an unpadded PATH_CHALLENGE (padding is refused because anti_ampl_limit <= max_datagram_size), and the peer answers. 3. on_path_resp_received sets verified_peer_address, which freezes anti_ampl_limit; the path is promoted to ValidatingMTU and probes again, needing a challenge padded to MIN_CLIENT_INITIAL_LEN. 4. need_expand_padding_frames still compares the frozen limit against max_datagram_size and refuses the padding — forever. The path never reaches Validated, never becomes active, and the server keeps sending user data to the stale address. Fix: skip the anti-amplification checks in both helpers once the peer address is verified, matching the semantics of the other three helpers. Address-validated paths are exempt from the 3x limit per RFC 9000 Section 8; the MTU-validating padded challenge is then allowed out and validation completes. Found while adding server-side NAT rebind handling; covered by the conn_multipath_nat_rebind test added in a follow-up commit (the test deadlocks at ValidatingMTU without this fix).
This was referenced Jul 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The server-side anti-amplification helpers (
inc/dec/cmp_anti_ampl_limit) all stop applying the limit onceverified_peer_addressis set — the limit value is frozen from that point on.need_send_validation_framesandneed_expand_padding_frames, however, keep consulting the frozen value.For a path opened by a small packet — exactly what a NAT rebinding looks like to a server — the sequence deadlocks:
anti_ampl_limitof only a few hundred bytes.anti_ampl_limit <= max_datagram_size), and the peer answers.on_path_resp_receivedsetsverified_peer_address, freezinganti_ampl_limit; the path is promoted toValidatingMTUand probes again, now needing a challenge padded toMIN_CLIENT_INITIAL_LEN.need_expand_padding_framesstill compares the frozen limit againstmax_datagram_sizeand refuses the padding — forever. The path never reachesValidated, never becomes active, and the server keeps sending user data to the stale address.Fix: skip the anti-amplification checks in both helpers once the peer address is verified, matching the semantics of the other three helpers (address-validated paths are exempt from the 3x limit per RFC 9000 §8).
Found while implementing server-side NAT rebind handling (#524 builds on this and adds a test that deadlocks at
ValidatingMTUwithout it). Full suite passes: 558/0.🤖 Generated with Claude Code