Skip to content

bgpd: Verify if we correctly parsed BGP-LS attribute#21344

Merged
cscarpitta merged 1 commit intoFRRouting:masterfrom
opensourcerouting:fix/bgp_ls_parse_attr
Mar 26, 2026
Merged

bgpd: Verify if we correctly parsed BGP-LS attribute#21344
cscarpitta merged 1 commit intoFRRouting:masterfrom
opensourcerouting:fix/bgp_ls_parse_attr

Conversation

@ton31337
Copy link
Copy Markdown
Member

No description provided.

The loop condition while (stream_get_getp(s) < end_pos) does not catch
overshooting. If a sub-parser (e.g. parse_prefix_sid) reads length bytes but
length was crafted to extend past end_pos, the stream pointer ends up beyond
end_pos.

The < condition then terminates the loop normally, and return 0 follows success,
with the stream pointer at the wrong offset.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented Mar 25, 2026

Greptile Summary

This PR adds a post-loop bounds check to bgp_ls_parse_attr() in bgpd/bgp_ls_nlri.c, verifying that the stream read position exactly matches the computed end_pos after all attribute TLVs have been processed.

  • The new check (stream_get_getp(s) != end_pos) follows the identical pattern already established in bgp_ls_decode_node_descriptor, bgp_ls_decode_link_descriptor, and bgp_ls_decode_prefix_descriptor within the same file.
  • It catches both under-consumption (a sub-parser read fewer bytes than its declared TLV length) and over-consumption (a sub-parser read more bytes than its declared TLV length, allowing the while-loop to exit early).
  • The caller in bgp_attr.c (line 4055) already handles the -1 return value by freeing the allocated attribute and returning BGP_ATTR_PARSE_ERROR, so no upstream changes are required.
  • The warning uses EC_BGP_LS_PACKET, consistent with the other length-mismatch warnings in the file.

Confidence Score: 5/5

  • Safe to merge — the change is a small, correct defensive check consistent with the established pattern in the same file.
  • The change is a 5-line addition that exactly mirrors three other identical checks already present in bgp_ls_nlri.c. The error code, return value, and caller handling are all correct. No new logic paths, no allocations, no side effects — purely a post-condition assertion on the stream position.
  • No files require special attention.

Important Files Changed

Filename Overview
bgpd/bgp_ls_nlri.c Adds a post-loop bounds check to bgp_ls_parse_attr that verifies the stream position exactly equals the expected end position, matching the same defensive pattern used in bgp_ls_decode_node_descriptor, bgp_ls_decode_link_descriptor, and bgp_ls_decode_prefix_descriptor. Caller in bgp_attr.c already handles the -1 return value correctly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["bgp_ls_parse_attr(s, total_length, attr)"] --> B["end_pos = getp + total_length"]
    B --> C{getp < end_pos?}
    C -->|yes| D["stream_get_tlv_hdr → type, length"]
    D -->|error| E["return -1"]
    D -->|ok| F["Dispatch on type\n(parse_* sub-functions)"]
    F -->|error| E
    F -->|ok| C
    C -->|no – loop exits| G{getp == end_pos?}
    G -->|yes| H["return 0 ✓"]
    G -->|no – NEW CHECK| I["flog_warn: Attribute length mismatch\nreturn -1"]
    H --> J["Caller in bgp_attr.c\nchecks ret != 0 → BGP_ATTR_PARSE_ERROR"]
    I --> J
Loading

Reviews (1): Last reviewed commit: "bgpd: Verify if we correctly parsed BGP-..." | Re-trigger Greptile

@cscarpitta cscarpitta merged commit 2176c8e into FRRouting:master Mar 26, 2026
24 checks passed
@ton31337 ton31337 deleted the fix/bgp_ls_parse_attr branch March 26, 2026 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants