php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #45220 curl_read callback returns -1 when needs to return size_t (unsigned)
Submitted: 2008-06-09 17:17 UTC Modified: 2008-08-13 20:18 UTC
Votes:3
Avg. Score:4.0 ± 0.8
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:0 (0.0%)
From: brockn at gmail dot com Assigned:
Status: Closed Package: cURL related
PHP Version: 5.2.6 OS: CentOS release 4.6 (Final)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
13 - 8 = ?
Subscribe to this entry?

 
 [2008-06-09 17:17 UTC] brockn at gmail dot com 
Description:
------------
curl_read, can return -1 when it explicitly states its return size_t. This causes curl versions >= 7.18.X to fail with the attached code.

Curl stores the callback return value as int, but casts it to a size_t to do a check. This causes the value to become very large and thus the check fails when it should not.

I tried to download a snapshot and check that out, but the site appears to be down.

Reproduce code:
---------------
<?php
$host= 'http://bashcurescancer.com/dump-request-variable.php';
$CR = curl_init();
curl_setopt($CR, CURLOPT_TIMEOUT, 60);
curl_setopt($CR, CURLOPT_URL, $host);
curl_setopt($CR, CURLOPT_POST, 1);
curl_setopt($CR, CURLOPT_FAILONERROR, true);
curl_setopt($CR, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($CR, CURLOPT_SSL_VERIFYPEER, 0);
$body = curl_exec( $CR );
$error = curl_error( $CR );
if( !empty( $error )) {
        print("FAIL: $error\n");
        exit(1);
} else {
        print("PASS: " . trim($body) . "\n");
        curl_close($CR);
        exit(0);
}
?>


Expected result:
----------------
PASS: array (

)

Actual result:
--------------
FAIL: Failed to open/read local data from file/application

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-06-09 19:07 UTC] brockn at gmail dot com 
Here are the details of the problem which occurs inside libcurl:

http://curl.haxx.se/mail/lib-2008-06/0109.html
http://curl.haxx.se/mail/lib-2008-06/0111.html
http://curl.haxx.se/mail/lib-2008-06/0123.html
 [2008-06-16 17:25 UTC] randearievilo at gmail dot com 
I have a similar code using cURL that worked fine in two platforms, but failed on other two.

Platforms working:
- Debian 4.0 / PHP 5.2.0 / Apache 2.2.8 / libcurl 7.15.5
- Windows XP / PHP 4.4.7 / Apache 1.3.39 / libcurl 7.16.0

Platforms not working:
- Linux / PHP 4.4.7 / Apache 1.3.41 / libcurl 7.18.1
- Linux / PHP 5.2.5 / Apache 1.3.41 / libcurl 7.18.1

As you can see, the libcurl 7.18.x may really have a bug/error/problem.
I think there was a change in the option CURLOPT_POST. Now, to use this option, it seems to be necessary to set the option CURLOPT_POSTFIELDS (curl_setopt($ch, CURLOPT_POSTFIELDS, "");).
 [2008-06-16 17:32 UTC] brockn at gmail dot com 
Yes, if you set POSTFIELDS to "", then curl_read does not return -1. The root of the problem is that the default return value is -1, when it should be 0 as it returns a size_t which is an unsigned type.

A check was added in libcurl 7.18 where the value is cast to size_t and compared. This is the ``effect'' of the problem, but the cause is that the php supplied curl_read callback is returning -1.
 [2008-07-12 20:34 UTC] nicolas at brousse dot info 
You can also simply "patch" php source by fixing line 789 in ext/curl/interface.c :

# before
int             length = -1;
# after
int             length = 0;
 [2008-07-12 21:20 UTC] felipe@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 [2008-08-13 18:55 UTC] brockn at gmail dot com 
Looks like php 4.4.9 is still broken. I know its not supported anymore, but people are going to be using it for quite some time so I'd think it might be prudent to fix it....given that its so simple.
 [2008-08-13 20:18 UTC] lstrojny@php.net 
PHP 4 is dead and no fixes, even the simplest, will be applied to it.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 13:01:27 2024 UTC