GHSA-8cfx-wx3q-mh5q — netty-incubator-codec-ohttp: Binary HTTP parser infinite loop on known-length field section boundary

Affected: Maven: io.netty.incubator:netty-incubator-codec-bhttp

## 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 reac…

Most recent entries from all

GHSA-8cfx-wx3q-mh5q — netty-incubator-codec-ohttp: Binary HTTP parser infinite loop on known-length field section boundary