Skip to content

bgp: fix stack buffer overflow in EVPN parseNlriData#100

Open
xq9mend wants to merge 1 commit intoSNAS:masterfrom
xq9mend:fix/f026-evpn-stack-buffer-overflow
Open

bgp: fix stack buffer overflow in EVPN parseNlriData#100
xq9mend wants to merge 1 commit intoSNAS:masterfrom
xq9mend:fix/f026-evpn-stack-buffer-overflow

Conversation

@xq9mend
Copy link
Copy Markdown

@xq9mend xq9mend commented Apr 24, 2026

Why I did it

ip_binary is a 16-byte stack buffer in EVPN::parseNlriData. The IP Address Length field read from wire data (1 byte) was divided by 8 to get addr_bytes, which can be up to 31. This value was passed directly to memcpy with no destination-size check, allowing up to 15 bytes of stack overflow. Three parsing paths were affected: type-2 (MAC-IP Advertisement), type-3 (IMET), and type-4 (ES).

How I did it

Added a clamp after the addr_bytes computation in all three paths:

if (addr_bytes > (int)sizeof(ip_binary)) addr_bytes = sizeof(ip_binary);

Also fixed the type-4 path to use the clamped addr_bytes in memcpy instead of the raw unclamped expression it previously used.

How to verify it

Build passes: cmake + make with no errors (tested on Ubuntu 24.04, gcc 13). No unit tests exist in this repo.

Add destination-size clamp before memcpy into ip_binary[16] in
three EVPN route-type parsing paths (type-2 MAC-IP, type-3 IMET,
type-4 ES). Wire-supplied ip_len field (1 byte) could produce
addr_bytes up to 31, overflowing the 16-byte stack buffer.

Fix: clamp addr_bytes to sizeof(ip_binary) before memcpy.
Signed-off-by: xq9mend <xq9mend@users.noreply.github.com>
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