bgpd: fix strlcat/strlcpy size parameter in NOTIFICATION send path

[guoguojia2021]

In bgp_notify_send_internal(), the hex-formatted notification data buffer is allocated with size bgp_notify.length * 3, since each byte is formatted as " %02x" (3 characters). However, the strlcat() and strlcpy() calls were incorrectly passed bgp_notify.length as the buffer size limit instead of bgp_notify.length * 3.

This caused severe truncation of the debug output string. For example, a 30-byte notification data would allocate a 90-byte buffer, but strlcpy would only allow writing 30 bytes, displaying roughly the first 10 bytes of hex values and silently discarding the rest.

The receive path (bgp_notify_receive) already correctly uses bgp_notify.length * 3 as the size limit for the same formatting logic. This fix makes the send path consistent with the receive path.

While strlcat/strlcpy are safe functions that truncate rather than overflow, the truncated output made NOTIFICATION debugging unreliable, potentially hiding critical protocol error details from operators during fault diagnosis.

[greptile-apps]

Greptile Summary

Fixes incorrect buffer size arguments in strlcat/strlcpy calls inside the BGP NOTIFICATION send path (bgp_notify_send_internal). The debug buffer is allocated as bgp_notify.length * 3 bytes (3 chars per hex byte), but the size guard was mistakenly passing bgp_notify.length, causing the hex output to be silently truncated to roughly one-third of the notification data.

• The allocation XMALLOC(MTYPE_BGP_NOTIFICATION, bgp_notify.length * 3) is unchanged; only the strlcat/strlcpy size arguments are corrected from bgp_notify.length to bgp_notify.length * 3.
• The receive path (bgp_notify_receive) already used inner.length * 3 correctly; this brings the send path into alignment with the same pattern.

Confidence Score: 5/5

Safe to merge — the change is narrowly scoped to two size arguments in a debug-only code block, with no effect on packet construction or protocol behavior.

Both changed lines are inside the /* For debug */ block and only affect how hex bytes are printed into a local string before being passed to bgp_notify_print. The buffer allocation size is unchanged and correctly sized at length * 3; the fix simply passes that same value to strlcat/strlcpy so the full payload is rendered. The receive path already used this exact pattern, confirming the intended approach. No data path, memory ownership, or protocol logic is touched.

No files require special attention.

Important Files Changed

Filename	Overview
bgpd/bgp_packet.c	Two-line fix: strlcat/strlcpy size arguments corrected from bgp_notify.length to bgp_notify.length * 3 to match the actual allocation size; debug output now displays the full notification data payload.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[bgp_notify_send_internal called] --> B{datalen > 0 and data != NULL?}
    B -- No --> E[bgp_notify.data = NULL]
    B -- Yes --> C[Allocate buffer: XMALLOC datalen * 3]
    C --> D[Loop i = 0..datalen-1]
    D --> F{first byte?}
    F -- Yes --> G[strlcpy with size datalen * 3]
    F -- No --> H[strlcat with size datalen * 3]
    G --> D
    H --> D
    E --> I[bgp_notify_print]
    D --> I
    I --> J[XFREE bgp_notify.data]

Loading

_{Reviews (1): Last reviewed commit: "bgpd: fix strlcat/strlcpy size parameter..." | Re-trigger Greptile}

[donaldsharp]

let's just set the correct size of bgp_notify.length on line 1011 instead of having to multiple *3 all over the place.

[guoguojia2021]

Thanks for the suggestion. Updated！

[donaldsharp]

Why is bgp_notify.length set to the correct value here and just use that?

[guoguojia2021]

Thanks for the suggestion. Updated to set bgp_notify.length = datalen * 3 directly.