Count HPACK header list entries with RFC 9113 per-entry overhead - #9733
Open
shaggyinsomniac wants to merge 1 commit into
Open
Count HPACK header list entries with RFC 9113 per-entry overhead#9733shaggyinsomniac wants to merge 1 commit into
shaggyinsomniac wants to merge 1 commit into
Conversation
The header list byte limit was computed as name.size + value.size, so a literal header field whose name and value are both empty contributed nothing to the accounting. A peer could send CONTINUATION frames (which are not flow controlled) containing 3-byte zero-length literal headers and grow the header list without the limit ever being exceeded. Account for the 32-byte per-entry overhead defined by RFC 9113 section 6.5.2, matching nghttp2 and Jetty, so every header entry consumes budget and the limit cannot be bypassed with empty entries. Signed-off-by: Sagar Chanchal <Sagarr2112@gmail.com>
shaggyinsomniac
force-pushed
the
hpack-header-limit
branch
from
August 27, 2026 13:11
3ef90ef to
ca635f5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The header list byte limit in
Hpack.Readerwas computed asname.size + value.size, so a literal header field whose name and value are both empty contributed zero bytes to the accounting:A peer can send HEADERS/CONTINUATION frames (not flow controlled) composed of these 3-byte entries and grow the header list indefinitely — one
Headerobject per 3 wire bytes, roughly 30-50x heap amplification — without the 256 KiBHEADER_LIMITever being exceeded.MAX_HEADER_LIST_SIZEis not enforced ("Advisory only" inHttp2Reader), so this is the only cap. Same class of issue as CVE-2024-27316 (nghttp2 CONTINUATION flood).Fix
Account for the 32-byte per-entry overhead defined by RFC 9113 §6.5.2 when a header is added, matching nghttp2 and Jetty. Every header entry now consumes budget regardless of name/value length, so zero-length entries cannot bypass the limit.
Test
manyEmptyHeadersExceedByteLimit— sends 8193 zero-length literal headers (24 KiB) and expects the reader to throw. Fails onmaster(the limit never trips) and passes with this change. FullHpackTestsuite (58 tests) passes.