CVE-2023-38039

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API.

However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server to stream an endless series of headers and eventually cause curl to run out of heap memory.

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API.

However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server to stream an endless series of headers and eventually cause curl to run out of heap memory.

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API.

However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server to stream an endless series of headers and eventually cause curl to run out of heap memory.

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API. However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server to stream an endless series of headers and eventually cause curl to run out of heap memory.

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API.

However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server to stream an endless series of headers and eventually cause curl to run out of heap memory.

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API. However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server to stream an endless series of headers and eventually cause curl to run out of heap memory.

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API.

However, curl did not have a limit on the size or quantity of headers it would accept in a response, allowing a malicious server to stream an endless series of headers to a client and eventually cause curl to run out of heap memory.

TELNET option IAC injection. (CVE-2023-27533)

SFTP path ~ resolving discrepancy. (CVE-2023-27534)

FTP too eager connection reuse. (CVE-2023-27535)

GSS delegation too eager connection re-use. (CVE-2023-27536)

HSTS double free. (CVE-2023-27537)

SSH connection too eager reuse still. (CVE-2023-27538)

UAF in SSH sha256 fingerprint check. (CVE-2023-28319)

siglongjmp race condition. (CVE-2023-28320)

IDN wildcard match. (CVE-2023-28321)

more POST-after-PUT confusion. (CVE-2023-28322)

HTTP headers eat all memory. (CVE-2023-38039)

These are all security issues fixed in the curl-8.3.0-1.1 package on the GA media of openSUSE Tumbleweed.

This update for curl fixes the following issues:

• CVE-2023-38039: Fixed possible DoS when receiving too large HTTP header. (bsc#1215026)

This update for curl fixes the following issues:

• CVE-2023-38039: Fixed possible DoS when receiving too large HTTP header. (bsc#1215026)