Fixes potential nil return from multiplexer.Conn.RemoteAddr()#54578
Merged
Fixes potential nil return from multiplexer.Conn.RemoteAddr()#54578
multiplexer.Conn.RemoteAddr()#54578Conversation
c876933 to
216a315
Compare
zmb3
approved these changes
May 6, 2025
rosstimothy
approved these changes
May 6, 2025
216a315 to
b32c0dd
Compare
original source address in a ProxyLine's TLVs
b32c0dd to
e276abf
Compare
Contributor
This was referenced May 7, 2025
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
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.
This PR fixes a regression that made it possible for
multiplexer.Conn.RemoteAddr()to return a nilnet.Addr. This bug was introduced by the addition of theproxy_protocol_allow_downgradefeature and happens when a genuine class E source address appears in aPROXYheader. The existing behavior assumed we would find an original source address TLV whenever a class E source address was present since they're technically reserved for experimental purposes. However GKE has a feature that allows for networking using class E addresses. I'm also fairly certain this same behavior would have appeared in conjunction with CloudFlare's pseudo IPv4 feature which was the original inspiration forproxy_protocol_allow_downgrade. The fix is to fallback to the proxy line's source address when an original address isn't found in the TLVs.changelog: Fixed an issue preventing connections due to missing client IPs when using class E address space with GKE or CloudFlare pseudo IPv4 forward headers.