When FRR receives a BGP capability message, the following call trace occurs when an attempt is made to parse it:

```
#0 bgp_capability_msg_parse() in bgpd/bgp_packet.c
#1 bgp_capability_receive() in bgpd/bgp_packet.c
#2 bgp_process_packet() in bgpd/bgp_packet.c
```

In `bgp_capability_msg_parse()`, an inproper calculation on the bounds of the available data is made.

```c
static int bgp_capability_msg_parse(struct peer *peer, uint8_t *pnt,
					bgp_size_t length)
{
	...
	end = pnt + length;

	while (pnt < end) {
		/* We need at least action, capability code and capability
		 * length. */
		if (pnt + 3 > end) {
			/* error ... */
		}
		...
		hdr = (struct capability_header *)(pnt + 1);

		...

		/* Capability length check. */
		if ((pnt + hdr->length + 3) > end) {
			/* error ... */
		}

		/* Fetch structure to the byte stream. */
		memcpy(&mpc, pnt + 3, sizeof(struct capability_mp_data));
		pnt += hdr->length + 3;

	}

	return BGP_PACKET_NOOP;
}
```

While the first length check is properly done, the second one relies on a value directly read from the packet without verification. `hdr->length` is used to check the remaining amount of data, but the actual amount read is `sizeof(struct capability_mp_data)`. This means that the size check can be bypassed, causing `memcpy()` to read out of bounds.

This issue could be exploited to trigger a segmentation fault, leading to denial of service, or cause undefined behavior via corrupt fields in `mpc`.

This issue was fixed with the following commit:
https://github.com/FRRouting/frr/commit/ff6db1027f8f36df657ff2e5ea167773752537ed