curl crashes when writing into invalid file handle
| Bug #48518 | curl crashes when writing into invalid file handle | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Submitted: | 2009-06-10 12:51 UTC | Modified: | 2009-06-28 10:05 UTC |
|
||||||||||
| From: | tony2001@php.net | Assigned: | iliaa (profile) | |||||||||||
| Status: | Closed | Package: | cURL related | |||||||||||
| PHP Version: | 5.*, 6CVS (2009-06-27) | OS: | * | |||||||||||
| Private report: | No | CVE-ID: | None | |||||||||||
[2009-06-10 12:51 UTC] tony2001@php.net
Description: ------------ curl_setopt() doesn't increase reference count of file pointers passed along with CURLOPT_FILE and CURLOPT_WRITEHEADER options, which leads to invalid read/writes and as a result - random crashes because FILE* pointer is destroyed before write(). Simple patch fixes this problem, but there is another one to consider: should the refcount be decreased when closing the cURL handle? Patch proposed: http://dev.daylessday.org/diff/curl_write_handle.diff Reproduce code: --------------- <?php $tmp_dir = "/tmp/2"; $urls = array( 'http://ru.php.net/manual/en/function.curl-errno.php', 'http://ru.php.net/manual/en/function.curl-multi-close.php', 'http://ru.php.net/manual/en/function.curl-multi-getcontent.php', 'http://ru.php.net/manual/en/function.curl-multi-remove-handle.php', ); $mh = curl_multi_init(); foreach ($urls as $url) { $ch = curl_init(); $tmp_url = parse_url($url); $tmp_file = $tmp_dir."/".basename($tmp_url['path']); $fp = fopen($tmp_file, "w"); curl_setopt($ch, CURLOPT_RETURNTRANSFER,0); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_FILE, $fp); curl_multi_add_handle($mh, $ch); } $running = 0; do { curl_multi_exec($mh, $running); } while ($running > 0); ?> Actual result: -------------- ==29222== Invalid read of size 2 ==29222== at 0x60411F9: fwrite (in /lib64/libc-2.8.so) ==29222== by 0x45078F: curl_write (interface.c:882) ==29222== by 0x5738691: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x5750CC2: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x574D8F3: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x5752F7B: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x575380A: curl_multi_perform (in /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x45736A: zif_curl_multi_exec (multi.c:216) ==29222== by 0x6340F6: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==29222== by 0x639955: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==29222== by 0x633386: execute (zend_vm_execute.h:104) ==29222== by 0x6045FA: zend_execute_scripts (zend.c:1188) ==29222== by 0x58FFDE: php_execute_script (main.c:2171) ==29222== by 0x6E904A: main (php_cli.c:1188) ==29222== Invalid write of size 8 ==29222== at 0x6041245: fwrite (in /lib64/libc-2.8.so) ==29222== by 0x45078F: curl_write (interface.c:882) ==29222== by 0x5738691: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x5750CC2: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x574D8F3: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x5752F7B: (within /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x575380A: curl_multi_perform (in /usr/lib64/libcurl.so.4.0.1) ==29222== by 0x45736A: zif_curl_multi_exec (multi.c:216) ==29222== by 0x6340F6: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==29222== by 0x639955: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==29222== by 0x633386: execute (zend_vm_execute.h:104) ==29222== by 0x6045FA: zend_execute_scripts (zend.c:1188) ==29222== by 0x58FFDE: php_execute_script (main.c:2171) ==29222== by 0x6E904A: main (php_cli.c:1188)
Patches
Pull Requests
History
AllCommentsChangesGit/SVN commits
[2009-06-10 13:41 UTC] tony2001@php.net
Found another piece of strange code: PHP_FUNCTION(curl_exec) .... ch->uses++; if (ch->handlers->write->method == PHP_CURL_RETURN && ch->handlers->write->buf.len > 0) { --ch->uses; smart_str_0(&ch->handlers->write->buf); RETURN_STRINGL(ch->handlers->write->buf.c, ch->handlers->write->buf.len, 1); } --ch->uses; ... What's the point in uses++ and immediate uses-- ?[2009-06-15 12:39 UTC] iliaa@php.net
[2009-06-26 17:33 UTC] rasmus@php.net
[2009-06-28 10:05 UTC] pajoye@php.net