Fixes for undefined behavior in the snmp decoder #1345
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Before After Is this OK? |
|
With the pcap: |
guyharris
reviewed
Jul 30, 2025
print-snmp.c
Outdated
| signbit = 0x80000000; | ||
| } | ||
| /* We can only store the low 32 bits of the given value. If we've | ||
| * shifted the sign bit away, we will restore it below. */ |
There was a problem hiding this comment.
Some additional commentary about the method used to store only the low 32 bits (i.e., masking the upper 8 bits away before shifting left by 8 bits), and an indication that this avoids undefined behavior, might be useful
There was a problem hiding this comment.
How about
/* In order to avoid undefined behavior, we mask off the low
* 24 bits of the data before shifting up by 8 bits. Either
* way, we lose the top 8 bits, but shifting through the sign
* bit results in undefined data. If we've shifted the sign
* bit away, we will restore it below. */
fxlb
force-pushed
the
fenner-snmp-ubsan-fixes
branch
from
7f180e4 to
28afdbc
Compare
|
Rebased. And no SNMP code path. |
|
With a new test file without "IPv6 problem": After Is this OK? |
|
New capture file |
It's using the snmp printer because it's UDP port 162 (trap). The ASN.1 value is an out of bounds negative number. The old behavior shifted the sign bit away; the new behavior retains the sign bit but the number is still not the one represented in the packet. I think it's OK. |
Instead of shifting bits off the top of the 32-bit value, we mask off the top 8 bits before shifting them away, and restore the sign bit at the end. This still results in a result that is not what was intended, as this code can not handle values greater than 2^31-1 or smaller than -2^31, but this new mechanism results in a "more correct" garbage out, with no undefined behavior.
When decoding an OID, and shifting left by 7, mask off the top 7 bits first. This still results in GIGO, but avoids undefined behavior on the way there. OIDs with values this large are not supported by this code.
fenner
force-pushed
the
fenner-snmp-ubsan-fixes
branch
from
28afdbc to
2eb5203
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These changes fix undefined behavior in the snmp decoder when the underlying representation is of a value larger than 32-bits. The decoder fundamentally doesn't support these values, and the original behavior is GIGO. We retain the same GIGO behavior, but avoiding undefined behavior.
Fixes #1054