Last Modified: Sep 02, 2026
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.1.2.2, 17.1.3, 17.1.3.1, 17.1.3.2, 17.1.3.4, 17.1.3.5, 17.5.0, 17.5.1, 17.5.1.2, 17.5.1.3, 17.5.1.4, 17.5.1.5, 17.5.1.6, 17.5.1.8, 17.5.1.9, 21.0.0, 21.0.0.1, 21.0.0.2, 21.0.0.3, 21.1.0, 21.1.0.1, 21.1.0.2
Opened: Jul 02, 2026 Severity: 3-Major
The BGPd process may unexpectedly terminate (either by core dump or restart) when creating UPDATE messages that include MP_REACH_NLRI or MP_UNREACH_NLRI attributes. This issue arises because the code accesses or writes to the message buffer without first ensuring that there is enough space available. As a result, this can lead to BGP session flaps and the potential loss of routing information during the restart
Without this fix, bgpd may access buffer memory without validating available space when encoding MP_REACH_NLRI/MP_UNREACH_NLRI attributes into an outgoing UPDATE message. This can lead to memory corruption or an out-of-bounds access, causing the bgpd process to crash and restart
This situation arises when BGP is either advertising or withdrawing routes for a multiprotocol address family, such as IPv6 or VPNv4/VPNv6. It occurs when the available space left in the outgoing UPDATE message buffer is less than what is required to encode the MP_REACH/MP_UNREACH attribute. This typically happens when the message is almost full, yet there is still additional NLRI that needs to be included
No direct workaround to prevent the condition; reducing the number of prefixes/attributes advertised per update cycle (e.g., lowering max prefixes per batch) may reduce the likelihood of hitting the boundary condition. If bgpd crashes, it will restart automatically and BGP sessions will re-establish, but reduce concurrent MP-BGP churn where possible until upgraded
None