test(ipv4): add embedded NUL and CRLF cases with trailing content#909
Open
vtushar06 wants to merge 2 commits into
Open
test(ipv4): add embedded NUL and CRLF cases with trailing content#909vtushar06 wants to merge 2 commits into
vtushar06 wants to merge 2 commits into
Conversation
Both invalid per RFC 2673 s3.2 (the dotted-quad grammar admits only ASCII digits and the literal dot; NUL and CR/LF are not in the grammar). C string parsers truncate at NUL (inet_aton, inet_pton) and inet_aton truncates at CR, accepting the prefix and silently dropping the trailing content - so a strict format check must reject the whole input rather than delegate.
jviotti
approved these changes
Jun 1, 2026
Member
jviotti
left a comment
There was a problem hiding this comment.
I like the null byte separator one. Definitely interesting for implementations rooted in C and similar languages. The \r\n case arguably might not yield new information compared to the existing \n case, but I'm not against it either.
I guess is is a common pattern and doesn't seem like a big deal to have it too.
Contributor
Author
|
Good point - you may be right that the \r\n case truncates the same way the existing \n test does, so it doesn't add a distinct code path. I'll drop it and keep just the NUL-byte case, which is the genuinely different one (C string terminator vs line terminator). Pushing that now. |
The \r\n case truncates the same way the existing trailing-newline test does, so it exercises no distinct code path. Keep only the NUL-byte case, which is the genuinely different one (C string terminator vs line terminator).
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
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.
Adds two cases that catch implementations relying on C-string parsers for the ipv4 format. Both are invalid per
RFC 2673 section 3.2(dotted-quad admits only ASCII digits and the literal dot; NUL and CR/LF are not in the grammar).192.168.0.1\u0000.evil.com- inet_aton and inet_pton truncate at the NUL byte and accept the prefix, dropping the ".evil.com" suffix silently.192.168.0.1\r\nHost: evil- inet_aton truncates at the CR and accepts the prefix, dropping the injected header content.The existing tests cover bare trailing whitespace (\n, \t). These cover the distinct case of an injected-content-after-truncation pattern that naive C-string-based validators miss. Added across draft4, draft6, draft7, draft2019-09, draft2020-12, and v1.