Skip to content

test(ipv4): add embedded NUL and CRLF cases with trailing content#909

Open
vtushar06 wants to merge 2 commits into
json-schema-org:mainfrom
vtushar06:ipv4-embedded-control-chars
Open

test(ipv4): add embedded NUL and CRLF cases with trailing content#909
vtushar06 wants to merge 2 commits into
json-schema-org:mainfrom
vtushar06:ipv4-embedded-control-chars

Conversation

@vtushar06
Copy link
Copy Markdown
Contributor

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.

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.
Copilot AI review requested due to automatic review settings May 30, 2026 11:42
@vtushar06 vtushar06 requested a review from a team as a code owner May 30, 2026 11:42
Copy link
Copy Markdown
Member

@jviotti jviotti left a comment

Choose a reason for hiding this comment

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

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.

@vtushar06
Copy link
Copy Markdown
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants