The vulnerability (CVE-2023-23916) description indicates an issue with how curl handles chained HTTP compression, where a cap on decompression steps was implemented on a per-header basis, allowing a malicious server to cause excessive resource allocation by using many headers. I was unable to fetch commit details directly using the tools. However, external research identified the fixing commit as 061319a97530f502514278919fd93192d1605c8d. Analysis of the changes in this commit (obtained from public sources like GitHub) shows modifications primarily in lib/content_encoding.c (function Curl_unencode_write) and lib/http.c (function Curl_http_readwrite_headers).
Curl_unencode_write in lib/content_encoding.c is where the actual decompression occurs. The patch introduces a per-request counter data->req.headerdecomp and checks this counter against MAX_ENCODING_RECURSION. This directly addresses the flaw of not having a proper per-request limit on decompression steps.
Curl_http_readwrite_headers in lib/http.c is modified to initialize data->req.headerdecomp = 0; for each new set of headers. This ensures the per-request counter is reset correctly, which was likely a missing part of the previous, flawed implementation.
The vulnerability manifested in Curl_unencode_write because it was the function executing the decompression steps without a proper aggregate limit for the request. Curl_http_readwrite_headers was involved in the sense that the necessary state (the per-request counter) was not correctly initialized or managed by it or related header processing logic prior to the fix.