Repository navigation
fix DHCP decode of data after the END option - #402
Merged
Merged
Conversation
decode_dhcp() read a length byte for the END option before handling it, so a DHCP message with non-zero bytes after END was rejected as a decode error whenever the byte following END exceeded the remaining length. RFC 2132 section 3.2 defines END as a single octet that marks the end of valid information, so stop parsing at END. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
decode_dhcp()reads a length byte for every option except PAD before it reachescase DHCP_OPTION_END. If a DHCP message has non-zero bytes after END and the byte following END is larger than the remaining length, the message is rejected withDECODE_ERROR(counted as an RX protocol error) and never reaches the DHCP client.RFC 2132 section 3.2 defines END as a single octet that marks the end of valid information, so the decoder now stops at END. The
case DHCP_OPTION_ENDthat this makes unreachable is removed.Testing
test_protocols_dhcp_end_option(an Offer with non-zero bytes after END). It fails without the change and passes with it.-DBNGBLASTER_TESTS=ON, RelWithDebInfo, gcc 13.3 on Ubuntu 24.04: builds without warnings,ctest4/4 passed.🤖 Generated with Claude Code