Skip to content

reject SETTINGS_HEADER_TABLE_SIZE larger than 2^31 - 1 - #9643

Open
basavaraj-sm05 wants to merge 1 commit into
lysine-dev:mainfrom
basavaraj-sm05:http2-settings-header-table-size
Open

reject SETTINGS_HEADER_TABLE_SIZE larger than 2^31 - 1#9643
basavaraj-sm05 wants to merge 1 commit into
lysine-dev:mainfrom
basavaraj-sm05:http2-settings-header-table-size

Conversation

@basavaraj-sm05

Copy link
Copy Markdown
Contributor

readSettings decodes each SETTINGS value with a signed readInt(), and the size-shaped settings are meant to be range checked right where they're read. SETTINGS_INITIAL_WINDOW_SIZE and SETTINGS_MAX_FRAME_SIZE both reject a value whose high bit is set, but the SETTINGS_HEADER_TABLE_SIZE branch is empty, so a peer that advertises a header table size of 2^31 or more lands a negative int in the Settings. That value clears the != -1 guard in Http2Writer.applyAndAckSettings and reaches hpackWriter.resizeHeaderTable, where minOf(negative, 16384) stays negative and maxDynamicTableByteCount goes negative with it; adjustDynamicTableByteCount then runs evictToRecoverBytes against an empty dynamic table and walks off the end into a null slot, so the write side throws NullPointerException rather than a protocol error and the encoder's byte accounting is left broken. I noticed it lining up which settings check their value against which don't. Rejecting a negative header table size in the reader, the same way the two neighboring settings already do, keeps the bad value out of the encoder, and valid sizes decode unchanged since okhttp caps its own table at 16 KiB regardless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant