This issue was discovered by Team Atlanta (@LeeSinLiang) 👍

Summary

ChunkedContentParser.parseChunkLength() had no overflow guard on the hex
chunk-size parsing loop. A crafted HTTP request with 16+ hex digits in the
chunk size overflows the long chunkSize to a negative value, which corrupts
the internal buffer pointer. On the next loop iteration isEol() dereferences
the corrupted pointer and the JVM crashes with SIGSEGV.

This is reachable over the network with an unauthenticated POST request
using Transfer-Encoding: chunked. The HTTP header parser does not validate
chunk sizes — that happens entirely in ChunkedContentParser, which processes
body data after headers pass validation.

The fix adds an overflow guard before each chunkSize * 16 accumulation step:
if chunkSize > Long.MAX_VALUE >>> 4, the next multiply would overflow a
positive long, so the input is rejected as a protocol violation. The server
logs the violation and disconnects the client cleanly.

Test plan

• Add ChunkedContentParserTest with 9 unit tests covering:
  • Original PoC payload (16 hex d digits)
  • All f digits overflow (0xFFFFFFFFFFFFFFFF = -1)
  • 17 hex digits (always exceeds 64 bits)
  • Exact overflow boundary (MAX_CHUNK_SIZE_BEFORE_SHIFT + 1)
  • Largest accepted value (Long.MAX_VALUE = 16 hex digits 7fffffffffffffff)
  • 15 hex f digits (below boundary, must be accepted)
  • Overflow in a second chunk (exercises skipEol=false path, verifies first chunk data delivered correctly)
  • Normal single-chunk and multi-chunk parsing (sanity checks)
• Verify with network-level PoC that the patched server rejects the malicious request and stays up

🤖 Generated with Claude Code