-
CVSS Score
-Basic Information
Technical Details
Vulnerability Intelligence
Miggo AI
Miggo AIMiggo AIMiggo AIRoot Cause AnalysisThe vulnerability (CVE-2024-2398) describes a memory leak when the number of received headers for an HTTP/2 server push surpasses the maximum allowed limit (1000), causing libcurl to abort the server push without freeing all allocated header memory.
The provided commit deca8039991886a559b67bcd6 addresses this by introducing a new function free_push_headers that correctly frees both the individual header strings and the array holding them. This new function is then used in several places.
on_header function (in lib/http2.c): This function is a callback invoked by the nghttp2 library when header frames are received. The patch shows that in the specific code path where the number of push headers exceeds the limit (if(stream->push_headers_alloc > 1000)), the cleanup was changed:
- Curl_safefree(stream->push_headers);
+ free_push_headers(stream);
The original line Curl_safefree(stream->push_headers); would free the stream->push_headers array itself, but not the individual header strings that had been allocated and whose pointers were stored in this array. This is the direct cause of the memory leak described in the CVE. The on_header function is where the condition (too many headers) is detected and where the faulty abort and cleanup logic resided.
Other modified functions (http2_data_done, push_promise): These functions also had their cleanup logic for push_headers replaced with calls to the new free_push_headers function. However, their original cleanup logic, upon inspection, already included loops to free individual header strings (e.g., for(i = 0; i<stream->push_headers_used; i++) free(stream->push_headers[i]);). While the new free_push_headers function provides a more robust and centralized cleanup, the primary vulnerability described (leaking headers when aborting due to the 1000-header limit) was specifically due to the incomplete cleanup in the error path of on_header.
Therefore, the on_header function is identified as the vulnerable function because it contained the specific faulty logic (not freeing individual header strings) that was triggered under the conditions described in the CVE, leading to the memory leak. The changes in other functions are primarily refactoring for consistency and robustness using the new common cleanup utility.