-
Notifications
You must be signed in to change notification settings - Fork 896
slow: Add OSSP support #1363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
slow: Add OSSP support #1363
Conversation
ND_PRINT("\n\tOUI: %s (0x%06x)", | ||
tok2str(oui_values, "Unknown", oui), | ||
oui); | ||
tlen -= 3; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
3d4edc8
to
0b37c57
Compare
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.