Bug 66240 - "Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255." error when subdomain is 4294967295
Summary: "Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255." error when...
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 9.0.x
Hardware: All All
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2022-08-26 12:31 UTC by junho85
Modified: 2022-08-29 13:53 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description junho85 2022-08-26 12:31:18 UTC
my coworker found this bug


in /etc/hosts add

run tomcat (9.0.65)
$ docker run -it --rm -p 8888:8080 tomcat:9.0

open browser and connect to http://4294967295.localhost:8888

26-Aug-2022 12:23:11.063 INFO [http-nio-8080-exec-1] org.apache.coyote.AbstractProcessor.parseHost The host [4294967295.localhost:8888] is not valid
 Note: further occurrences of request parsing errors will be logged at DEBUG level.
	java.lang.IllegalArgumentException: Invalid octet [-1]. The valid range for IPv4 octets is 0 to 255.
		at org.apache.tomcat.util.http.parser.HttpParser.readHostIPv4(HttpParser.java:731)
		at org.apache.tomcat.util.http.parser.Host.parse(Host.java:73)
		at org.apache.tomcat.util.http.parser.Host.parse(Host.java:45)
		at org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:298)
		at org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:793)
		at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:375)
		at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
		at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890)
		at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
		at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
		at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
		at java.base/java.lang.Thread.run(Thread.java:833)
Comment 1 Stefan Mayr 2022-08-26 19:31:54 UTC
Interesting find. https://github.com/apache/tomcat/blob/831a674f7c12351cc3b537e899e7f20cb4d954ad/java/org/apache/tomcat/util/http/parser/Host.java#L65-L84 does not completely follow RFC 1123

Section 2.1 has this paragraph:
           If a dotted-decimal number can be entered without such
           identifying delimiters, then a full syntactic check must be
           made, because a segment of a host domain name is now allowed
           to begin with a digit and could legally be entirely numeric
           (see Section  However, a valid host name can never
           have the dotted-decimal form #.#.#.#, since at least the
           highest-level component label will be alphabetic.

Looking at https://github.com/apache/tomcat/blob/831a674f7c12351cc3b537e899e7f20cb4d954ad/java/org/apache/tomcat/util/http/parser/HttpParser.java#L718-L719 rings a bell

4294967295 is 0xffff which should be -1 for Java int. That explains why it passes the condition in https://github.com/apache/tomcat/blob/831a674f7c12351cc3b537e899e7f20cb4d954ad/java/org/apache/tomcat/util/http/parser/HttpParser.java#L734 to throw that exception instead of following the else to fall back to readHostDomainName
Comment 2 Stefan Mayr 2022-08-26 19:40:07 UTC
This also work for other values like 8589934591 (0x1ffff) which result in an int overflow and produces 0xffff (-1) as a result
Comment 3 Han Li 2022-08-29 13:52:46 UTC
Thanks for the feedback.

Fixed in:
- 10.1.x for 10.1.0-M18 onwards
- 10.0.x for 10.0.24 onwards
- 9.0.x for 9.0.66 onwards
- 8.5.x for 8.5.83 onwards