CVE-2026-63124

## Summary `io.netty.incubator:netty-incubator-codec-bhttp` can enter a non-terminating parse loop when a known-length Binary HTTP field section ends exactly after a complete field line. A remote peer that can send Binary HTTP input to a Netty pipeline using `BinaryHttpParser` / `BinaryHttpDecoder` can use a tiny malformed request or response to keep the parsing thread busy indefinitely, causing denial of service. ## Details In `codec-bhttp/src/main/java/io/netty/incubator/codec/bhttp/BinaryHttpParser.java`, `readFieldSection(...)` tracks the remaining field-section length in `fieldSectionLength`, then repeatedly calls `readFieldLine(...)` until the length reaches zero: - `readFieldSection(...)` parses the known-length field section and enters `while (fieldSectionLength != 0)` at `BinaryHttpParser.java:619`. - Inside the loop, it records `readableBytes`, calls `readFieldLine(...)`, computes `read = readableBytes - in.readableBytes()`, asserts `read > 0`, and subtracts `read` from `fieldSectionLength` at `BinaryHttpParser.java:620-625`. - `readFieldLine(...)` returns `null` without consuming bytes when the field line ends exactly at the end of the readable slice because it uses `if (sumBytes >= in.readableBytes()) return null` after adding the value length (`BinaryHttpParser.java:678-681`). - With JVM assertions disabled (the production default), `assert read > 0` is not active. The parser therefore subtracts zero forever and never returns. The boundary condition is reachable with a valid known-length field section containing exactly one complete field line and no extra byte after that line. Example field section: length `4`, then name length `1`, name `a`, value length `1`, value `b`. ## Proof of concept Safe local verification performed in this repository: 1. Compile the module and classpath: ```bash ./mvnw -q -pl codec-bhttp -am compile test-compile ./mvnw -q -pl codec-bhttp dependency:build-classpath -Dmdep.outputFile=/tmp/codec-bhttp-cp.txt printf '%s'