I did this
Summary:
In Curl_cpool_check_limits, there's a loop (conncache.c:319) that removes connections from a bundle until the number of connections is less than the configured maximum.
However, if the maximum is 1, the loop will remove all connections, causing the bundle to be deleted in the call to Curl_cpool_disconnect (conncache.c:331).
This leaves the pointer in Curl_cpool_check_limits dangling, and when the loop condition is checked the freed bundle is accessed.
Steps To Reproduce:
We first noticed this in our valgrind testruns.
A simple way to reproduce it is to hardcode the dest_limit to 1 in Curl_cpool_check_limits, and run a test that exercises this, for example 2032.
It should fail with valgrind warnings about invalid reads.
The test stderr should show: * Discarding Connection #0 from 1 to reach destination limit of 1
I expected the following
No response
curl/libcurl version
commit d9a9233
operating system
Linux *** 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
I did this
Summary:
In Curl_cpool_check_limits, there's a loop (conncache.c:319) that removes connections from a bundle until the number of connections is less than the configured maximum.
However, if the maximum is 1, the loop will remove all connections, causing the bundle to be deleted in the call to Curl_cpool_disconnect (conncache.c:331).
This leaves the pointer in Curl_cpool_check_limits dangling, and when the loop condition is checked the freed bundle is accessed.
Steps To Reproduce:
We first noticed this in our valgrind testruns.
A simple way to reproduce it is to hardcode the dest_limit to 1 in Curl_cpool_check_limits, and run a test that exercises this, for example 2032.
It should fail with valgrind warnings about invalid reads.
The test stderr should show: * Discarding Connection #0 from 1 to reach destination limit of 1
I expected the following
No response
curl/libcurl version
commit d9a9233
operating system
Linux *** 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux