The vulnerability CVE-2024-29025 in Netty's HttpPostRequestDecoder allows for OutOfMemoryErrors (OOM) due to two primary issues: unbounded accumulation of bytes in an internal buffer (undecodedChunk) during field decoding, and no limit on the total number of form fields, leading to potential unbounded growth of the bodyListHttpData list.
The provided patch (commit 0d0c6ed782d13d423586ad0c71737b2c7d02058c) addresses these vulnerabilities by introducing two new configurable limits: maxBufferedBytes for the size of the undecodedChunk and maxFields for the maximum number of attributes a form can have. These limits are now enforced within the decoding logic.
The vulnerable functions are identified by observing where these crucial limit checks were absent in the pre-patch code and were subsequently added by the patch:
- The
offer methods in both HttpPostMultipartRequestDecoder and HttpPostStandardRequestDecoder were vulnerable because they processed incoming data and populated the undecodedChunk without checking its size against maxBufferedBytes.
- The
addHttpData methods in both HttpPostMultipartRequestDecoder and HttpPostStandardRequestDecoder were vulnerable because they added parsed data to the bodyListHttpData list without checking the total number of fields against maxFields.
- Several constructors of
HttpPostMultipartRequestDecoder, HttpPostStandardRequestDecoder, and the main facade class HttpPostRequestDecoder are also identified as contributing to the vulnerability. Specifically, constructors that did not accept or internally apply these limits would create decoder instances that were inherently unsafe and susceptible to the OOM conditions when their offer or addHttpData methods were invoked. The patch modifies these existing constructors to either accept the new limit parameters directly or to delegate to new overloaded constructors that do, applying default values for these limits to ensure safety.
The evidence for each function's vulnerability is derived directly from the patch: the addition of specific boundary checks (e.g., if (maxBufferedBytes > 0 && ...) or if (maxFields > 0 && ...)) or the modification of constructor logic to incorporate these limits clearly indicates that the absence of these measures in the prior versions constituted the security flaw.