server: bound the RTR message length before allocating the body - #3579
Open
Mounika2456 wants to merge 1 commit into
Open
server: bound the RTR message length before allocating the body#3579Mounika2456 wants to merge 1 commit into
Mounika2456 wants to merge 1 commit into
Conversation
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.
The RTR client read loop in (*roaClient).established reads the 4-byte Length field from an RTR PDU header and then does make([]byte, totalLen-RTR_MIN_LEN) for the body. totalLen is a 32-bit value taken straight off the wire and is only checked against the lower bound (RTR_MIN_LEN); nothing caps it. A cache that sends an 8-byte header declaring Length 0xffffffff drives a ~4 GiB allocation before a single body byte is read. On the 386 and arm builds that request is larger than the address space, so the runtime aborts with a fatal out-of-memory error and gobgpd dies.
Add an upper bound (RTR_MAX_LEN, 65535) next to the existing lower-bound check and move the framing into readRTRMessage so the declared length is validated before the body slice is sized. The ceiling sits well above every defined PDU and mirrors the 16-bit length limit already enforced on BGP and ZAPI messages. RTRErrorReport.DecodeFromBytes already bounds its own Length for the same reason, but that runs after the framer has allocated, so the cap belongs at the read.