[binaryfire]

I ran into this while working on Swoole's copy of ext/curl, which we keep in line with php-src.

The description below was written by Claude at my request, and I've reviewed it.

curl_reset() resets the write, header and read handlers but doesn't release their callbacks. It also keeps the CURLOPT_PRIVATE value and the CURLOPT_POSTFIELDS array, so all of these stay referenced until the handle is freed:

• Callback objects and closures, and anything they capture, stay alive while a reset handle is pooled for reuse.
• curl_getinfo($ch, CURLINFO_PRIVATE) still returns the old value after a reset.
• curl_copy_handle() and clone of a reset handle rebuild the old file post fields.

Guzzle's CurlFactory works around the first one by setting each callback to null before it calls curl_reset() on a handle it pools. Its code comment says the callbacks "can hold onto references and are not cleaned up by curl_reset".

Separately, when a CURLOPT_POSTFIELDS array containing a CURLFile or CURLStringFile is replaced with another value, the old array isn't released. The original handle sends the new body, but curl_copy_handle() and clone rebuild the old multipart body on the copy.

The same array is also kept when CURLOPT_HTTPGET, CURLOPT_NOBODY, CURLOPT_POST, CURLOPT_UPLOAD or CURLOPT_PUT changes the request method afterwards. For example, after CURLOPT_HTTPGET the original handle sends a GET, but the copy goes back to a multipart POST with the old file.

This PR releases the three callbacks, the private value and the post fields array in curl_reset(). It also drops the stored array when CURLOPT_POSTFIELDS is set again, or when one of those method options is set.

A destructor that calls curl_setopt() for the same option while curl_reset() is releasing it can still cause a use-after-free. That's already possible for the progress, xferinfo and other callbacks released there, so I've left it to the general destructor work in #20001.

[anun333]

Quoted below: written with Claude, an LLM, as CONTRIBUTING.md asks us to mark. The builds and test runs behind it are on my machine; the commands to repeat them are under the fold.

Tested on today's PHP-8.4 (c7ea9b17582) with this applied, debug builds:

	PHP-8.4	this PR
the three new tests	FAIL	PASS
ext/curl/tests	150 passed, 3 failed (the new ones), 17 skipped	153 passed, 0 failed, 17 skipped
a write callback capturing an object, released	when the handle is freed	at curl_reset()
curl_getinfo($ch, CURLINFO_PRIVATE) after curl_reset()	'request 1'	false

So a reset handle no longer keeps what the request before it set, which is what curl_easy_reset() promises for the handle itself.

How this was tested

Linux x86_64, gcc 13.3, libcurl 8.5.0, debug builds of origin/PHP-8.4 and of it with this PR's commit cherry-picked:

./buildconf --force
./configure --enable-debug --disable-cgi --disable-phpdbg --disable-fileinfo --enable-pcntl --enable-zend-test --enable-fpm --with-curl --enable-mbstring --disable-mbregex
make -j4

The callback check: curl_setopt($ch, CURLOPT_WRITEFUNCTION, function ($c, $d) use ($o) { return strlen($d); }) with $o an object whose __destruct() echoes, CURLOPT_PRIVATE set to 'request 1', then unset($o), curl_reset($ch), curl_getinfo($ch, CURLINFO_PRIVATE), unset($ch). Tests: TEST_PHP_EXECUTABLE=$PWD/sapi/cli/php sapi/cli/php run-tests.php -n -q -j4 ext/curl/tests (the new tests copied into the PHP-8.4 tree for its run).

[Sjord]

Thank you for your contribution. I agree that this is a bug. I expect PHP's curl_reset to have the same effect as curl_easy_reset:

Re-initializes all options previously set on a specified curl handle to the default values. This puts back the handle to the same state as it was in when it was created with curl_easy_init.

So that means that CURLINFO_PRIVATE should be unavailable after a curl_reset.

At first glance this PR looks good, but incomplete. There are other fields that are not reset, such as curl_errno. That does not necessarily have to be a blocker for this PR.