php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69619 wrong argument for memcpy in from_zval_write_control
Submitted: 2015-05-11 07:19 UTC Modified: 2015-06-17 20:36 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: herumi at nifty dot com Assigned: pollita (profile)
Status: Closed Package: Sockets related
PHP Version: 5.5.24 OS: all
Private report: No CVE-ID: None
 [2015-05-11 07:19 UTC] herumi at nifty dot com
Description:
------------
The code ext/sockets/conversion.c:914 in php-5.5.24

if (space_left < req_space) {
    *control_buf = safe_erealloc(*control_buf, 2, req_space, *control_len);
    *control_len += 2 * req_space;
    memset(*control_buf, '\0', *control_len - *offset);      // (A)
    memcpy(&alloc->data, *control_buf, sizeof *control_buf); // (B)
}

Maybe th code (B) fill alloc->data with 8-byte zeros
because (A) fills *control_buf with zeros,
then the value of *control_buf is lost.

cf. https://github.com/php/php-src/blob/master/ext/sockets/conversions.c#L893

Is the correct code as the following?
memcpy(&alloc->data, control_buf, sizeof *control_buf);




Patches

fix_from_zval_write_control.diff (last revision 2015-05-11 07:19 UTC by herumi at nifty dot com)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-05-30 16:07 UTC] pollita@php.net
-Status: Open +Status: Feedback
 [2015-05-30 16:07 UTC] pollita@php.net
Looking at the code, your analysis certainly seems to be correct, and I'm happy enough to apply the fix (including to prior supported branches), but I'd like to include a regression test.  Do you have some reproduce code for this?

I realize that the bug presents itself in the form of a leak, but developer builds usually have --enable-debug turned on which produce leak warnings, so any repro which triggers the leak should properly fail any test case which uses this code path.
 [2015-05-30 16:15 UTC] pollita@php.net
In fact, that memset feels wrong as well.  I would assume it wants to clear the >end< of the buffer, not the beginning.  Hence:

memset(*control_buf + *offset, '\0', *control_len - *offset);
 [2015-05-31 22:45 UTC] cataphract@php.net
I agree with everything.

The memcpy should be copying the value of the reallocated pointer, not the data it points to and in fact the memset looks suspicious from the onset because you usually see memcpy(&foo, &bar, sizeof(bar)), i.e., one extra level of indirection in the 2nd argument.

And yes the memset looks like it should start at ((char*)*control_buf) + *offset) (zero the newly allocated segment).

I guess this branch was never exercised in the tests. Sorry for the trouble.
 [2015-06-07 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2015-06-07 13:59 UTC] cmb@php.net
-Status: No Feedback +Status: Open
 [2015-06-13 02:20 UTC] pollita@php.net
-Assigned To: +Assigned To: pollita
 [2015-06-13 02:20 UTC] pollita@php.net
Thanks for confirming my thoughts! I'll merge this soon (unless you get to it first)
 [2015-06-17 20:36 UTC] pollita@php.net
-Status: Assigned +Status: Closed
 [2015-06-17 20:36 UTC] pollita@php.net
The fix for this bug has been committed.

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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Jun 28 04:03:34 2022 UTC