CVE-2022-41717: golang.org/x/net/http2 vulnerable to possible excessive memory growth

The vulnerability CVE-2022-41717 concerns excessive memory growth in a Go HTTP/2 server due to large header keys. The fix involves limiting the header cache by bytes, not just by the number of entries. I analyzed the likely code paths for HTTP/2 header processing and HPACK decoding based on the vulnerability description and the commit message 'x/net/http2: incoming header list size limit' associated with the fix (though direct diff fetching failed).

The primary changes involve:

1. Introducing a maxHeaderListSize at the http2.Server level, which is then used by serverConn.
2. Modifying (*serverConn).readMetaFrame to use this limit to configure the hpack.Decoder via SetMaxStringLength (to limit individual header field sizes) and to check the total decoded size via BytesLength.
3. Enhancing hpack.Decoder (specifically emit method) and hpack.dynamicTable (specifically add method) to track and limit the total byte size of header strings stored in the dynamic table, not just the number of entries or per-entry sizes.

The identified functions are central to these patched mechanisms:

• (*serverConn).readMetaFrame is the entry point in http2/server.go that orchestrates header decoding and now applies the overall byte limit for a header list.
• (*hpack.Decoder).emit and (*hpack.dynamicTable).add are in the http2/hpack/ package and are responsible for the low-level mechanics of adding headers to the dynamic table. Before the patch, their mechanisms for limiting memory were insufficient against attacks using many large keys, leading to the vulnerability. The patch added more robust byte-size tracking and limiting within these functions.

The confidence is high because these functions directly correspond to the areas (HTTP/2 server header processing and HPACK dynamic table management) where byte-based limits would be introduced to mitigate the described vulnerability. The failure to fetch commit diffs via tools means patch evidence is descriptive based on the commit message and file paths involved in the CL, rather than direct code snippets from the patch.