Skip to content

server: bound the RTR message length before allocating the body - #3579

Open
Mounika2456 wants to merge 1 commit into
osrg:masterfrom
Mounika2456:rtr-message-length-bound
Open

server: bound the RTR message length before allocating the body#3579
Mounika2456 wants to merge 1 commit into
osrg:masterfrom
Mounika2456:rtr-message-length-bound

Conversation

@Mounika2456

Copy link
Copy Markdown
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant