bgpd: fix integer overflow in maximum prefix threshold check#22439
Conversation
Greptile SummaryThis PR fixes an integer overflow in the BGP maximum-prefix threshold check inside
Confidence Score: 5/5The change is a single targeted cast that corrects arithmetic promotion in the threshold warning path and has no effect on the hard-limit or session-teardown paths. The fix is a single-line cast from uint32_t to uint64_t before a multiplication. The hard-limit comparison on line 5306 is unaffected. The pcount operand on the left side of the threshold comparison is uint32_t and is safely widened for the comparison. The maximum product after the cast (UINT32_MAX × 100) is well within uint64_t range, and the result after dividing by 100 fits back within uint32_t range, so the comparison semantics are preserved in all non-overflow cases and corrected in overflow cases. No files require special attention. Important Files Changed
Reviews (1): Last reviewed commit: "bgpd: fix integer overflow in maximum pr..." | Re-trigger Greptile |
bgp_maximum_prefix_overflow() computes the warning threshold as:
pcount > (peer->pmax[afi][safi] * peer->pmax_threshold[afi][safi] / 100)
Both operands are unsigned integers (pmax is uint32_t, pmax_threshold
is uint8_t), so the multiplication is performed in uint32_t arithmetic.
When pmax exceeds ~16.7 million (2^24) and the threshold is high
(e.g. 75–100), the product overflows uint32_t, wrapping to a small
value. This makes the comparison almost always false, silently
disabling the prefix threshold warning.
RFC 7454 Section 8 recommends maximum prefix limits as a critical
defense mechanism against route table exhaustion and runaway BGP
sessions. An overflow that silently disables the threshold warning
undermines this protection: a peer can continue advertising prefixes
well past the configured warning threshold without any log message or
notification, delaying operator awareness until the hard limit is
reached (or the router runs out of memory).
Cast pmax to uint64_t before the multiplication so the product is
computed in 64-bit arithmetic, correctly handling prefix limits up to
the uint32_t maximum (~4 billion) with any threshold percentage.
Signed-off-by: guozhongfeng.gzf <guozhongfeng.gzf@alibaba-inc.com>
552a379 to
a2ae427
Compare
Cast pmax to uint64_t before the multiplication so the product is computed in 64-bit arithmetic, correctly handling prefix limits up to the uint32_t maximum (~4 billion) with any threshold percentage.