elixir-mint / mint / b662d127d3028b5426c88d4c9cc7fe430491a10b

88%

push

github

Merge commit from fork

A malicious or compromised HTTP/2 server could exhaust client memory by
sending a HEADERS frame without END_HEADERS followed by an unbounded chain
of CONTINUATION frames. Each fragment was appended to
`conn.headers_being_processed` with no cap on size or count, and the block is
only decoded once END_HEADERS arrives — which a hostile server simply never
sends. A single connection could drive the client to OOM (~1 GiB from ~64k
16 KiB frames in the reported PoC).

The client now bounds the accumulated header block by the locally advertised
SETTINGS_MAX_HEADER_LIST_SIZE, which defaults to 256 KB (previously
:infinity, i.e. unbounded). The limit is checked against the compressed
accumulator as each fragment is parked, before it grows, and the connection
is torn down with a PROTOCOL_ERROR GOAWAY once exceeded. The default is also
advertised to the server so well-behaved peers never send oversized blocks;
the receive-side check backstops misbehaving ones. Because the compressed
accumulator is never larger than the header list it decodes to, the limit
never rejects a header block that fits within the advertised size.

The bound is tracked with a running byte count carried in
`headers_being_processed`, so enforcement is O(1) per frame rather than
rescanning the accumulator (which would be O(n^2) under a flood).

15 of 16 new or added lines in 1 file covered. (93.75%)

1379 of 1564 relevant lines covered (88.17%)

249.63 hits per line