-
Notifications
You must be signed in to change notification settings - Fork 78
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
Multiple issues with IPv6 and IPvFuture literal parsing #146
Comments
Hi @yescallop, thanks for bringing this to my attention. From a quick look all three of these are bugs. I will have a closer look. |
Hi @hartwork, I wonder if you'd have time to take a look at this? Thanks :) |
@yescallop I have been busy with work for the most part, but it's not forgotten. Are you blocked by these very bugs somewhere? |
Nope, actually. But I think I've figured out a fix now :) I'll open a PR to close this if extra fuzzing goes fine. |
Hi again @yescallop, I found some time to check your report against the related RFCs 3986 and 3513 now, for a start:
Confirming as a bug, 7 + 1 + 1 > 8.
Confirming as a bug.
Confirming as a bug. I wish that RFC 3986 would show that in the grammar better.
Confirming as a bug.
Confirming as a bug, 6 + 1 + 2 > 8. Excellent work, thanks for these reports! |
I found several issues with IP literal parsing in
uriparser
when fuzzingfluent-uri
against this library. Here's a list of them:::
in an IPv6 address indicates one or more groups of 16 bits of zeros. However, parsing//[0:0:0:0:0:0:0::1]
succeeds.:
that is not part of a::
is not permitted in an IPv6 address, but parsing//[:1::1:]
succeeds.v
of an IPvFuture is case-insensitive (see RFC 3986), but parsing//[VF.addr]
fails.//[::1.1.1.11]
and//[::1.1.1.111]
succeeds somehow, but parsing//[::1.1.1.100]
fails.//[1:1:1:1:1:1::1.1.1.1]
succeeds.Here's my fuzz target against
uriparser
which I hope could help: against_uriparser.rs.The text was updated successfully, but these errors were encountered: