Preface: FRRouting is a free IP protocol suite. Many companies: ISPs, SaaS, web 2.0 businesses, hyper-scale services, and Fortune 500 private clouds — use it as a fundamental part of their networks.
Background: FRRouting (FRR) is a free and open source Internet routing protocol suite for Linux and Unix platforms. It implements BGP, OSPF, RIP, IS-IS, PIM, LDP, BFD, Babel, PBR, OpenFabric and VRRP, with alpha support for EIGRP and NHRP.
BGP uses 4 messages: open, update, keepalive and notification. NOTIFICATION messages are used to signal when something is wrong with the BGP session. A NOTIFICATION will be sent when any of the following occurs: An unsupported option is sent in an OPEN message. A peer fails to send an update or keepalive.
Vulnerability details: An issue was discovered in bgpd in FRRouting (FRR) 8.3. In bgp_notify_send_with_data() and bgp_process_packet() in bgp_packet.c, there is a possible use-after-free due to a race condition. This could lead to Remote Code Execution or Information Disclosure by sending crafted BGP packets. User interaction is not needed for exploitation.
My speculation: As soon as the real BGP speaker communicates again (keepalive), an ACK storm ensues due to the overlapping sequence numbers. Refer to diagram, the file (bgp_packet.c). The BGP_MSG_KEEPALIVE contains operations tagged “memory_order_relaxed”.
Atomic operations tagged memory_order_relaxed are not synchronization operations; they do not impose an order among concurrent memory accesses. Perhaps this is one of the possibility to encountered similar design weakness.
CWE-416: Use After Free
The memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process.
Ref: A use-after-free bug due to race conditions in 2 threads. · Issue #11698 · FRRouting/frr · GitHub – https://github.com/FRRouting/frr/issues/11698