Skip to content

Conversation

corubba
Copy link

@corubba corubba commented Sep 23, 2025

Add basic printing of "Organization Specific Slow Protocol" (OSSP), which is standardized in IEEE 802.3 Annex 57B. Since this is used for non-standardized protocols and thus carries mostly unknown-structured data, most of the packet is still printed verbatim.

Also add the OUI of ITU-T that is used as part of its "Ethernet synchronization messaging channel" (ESMC) protocol, which is based on OSSP.

ND_PRINT("\n\tOUI: %s (0x%06x)",
tok2str(oui_values, "Unknown", oui),
oui);
tlen -= 3;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can see, this line can cause an out-of-bounds read: neither slow_ossp_print() nor its caller ensure that here tlen >= 3. Please add a length check.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GET_BE_U_3 does a length check, and will not return if there is not enough data. You can find the same pattern in other protocols, for example here, here and here. Worked fine when I tested it reducing the packet step by step one byte at a time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this context the GET_ macros guard the boundaries of the actually present (captured) data, and tlen is the declared data length. Please note:

  • the ND_ICHECK_U(len, <, 8); just before the data fetch in the first example,
  • the if (subtlv_len >= 6) around the data fetch in the second example, and
  • the if (len < length * NSH_HDR_WORD_SIZE) before the data fetch in the third example.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand how tlen could ever be less than the captured data (the other way around sure), and thus tlen < 3 not always first trigger the GET_BE_U_3 longjump. But I will assume you know better and submit to your judgement.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the reason is to have the correct message in the output, truncated packet (due to snaplen) vs invalid packet (simply too short).

Add basic printing of "Organization Specific Slow Protocol" (OSSP),
which is standardized in IEEE 802.3 Annex 57B. Since this is used for
non-standardized protocols and thus carries mostly unknown-structured
data, most of the packet is still printed verbatim.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

2 participants