returning reference to uninitialized variable

Bug #22836

Submitted:

2003-03-23 22:53 UTC

Modified:

2003-07-30 11:53 UTC

Votes:	3
Avg. Score:	5.0 ± 0.0
Reproduced:	3 of 3 (100.0%)
Same Version:	2 (66.7%)
Same OS:	2 (66.7%)

From:

brunswim at seas dot upenn dot edu

Assigned:

Status:

Closed

Package:

Scripting Engine problem

PHP Version:

4.3.2-RC

OS:

Debian Linux 2.4.18

Private report:

CVE-ID:

None

[2003-03-23 22:53 UTC] brunswim at seas dot upenn dot edu

f() returns a reference to an uninitialized variable $a. In subsequent calls, this appears to corrupt the local variable $x. The following script demonstrates the problem.

<?
function &f() {
	$x = "foo";
	var_dump($x);
	print "<br>\n$x<br>\n";
	return($a);
}
for ($i = 0; $i < 8; $i++) {
	$h =& f();
}
?>

On the third call to f(), $x prints fine but is reported to be NULL by var_dump().  Operations on $x will subsequently cause unexpected behavior.

We can change the behavior of $x by adding the line:
$y = "bar";
after the line:
$x = "foo";

If we do this, printing $x returns "bar" but var_dump() still returns NULL.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2003-03-24 01:45 UTC] brunswim at seas dot upenn dot edu

For the record, the output I am getting for this script is:

string(3) "foo"
foo
string(3) "foo"
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo
NULL
foo

[2003-03-24 03:41 UTC] sniper@php.net

I get same output plus these leaks:

/usr/src/web/php/php4/Zend/zend_execute.c(436) :  Freeing 0x0875A804 (4 bytes), script=t.php
/usr/src/web/php/php4/Zend/zend_variables.c(111) : Actual location (location was relayed)
/usr/src/web/php/php4/Zend/zend_execute.c(1702) :  Freeing 0x0875A6EC (12 bytes), script=t.php

[2003-03-24 04:29 UTC] moriyoshi@php.net

This problem has much to do with bug #22367.

Assumed reason: unexpected change of EG(uninitialized_zval_ptr)..

[2003-03-24 11:39 UTC] brunswim at seas dot upenn dot edu

This seems similar to bug #22367 but causes problems more globally.  Obviously, this is reproducible with a short script.  In the following similar example, it may be more apparent that global corruption is taking place.

<?
function &f1() {
	return($a);
}
function f2() {
	$x = "bar";
	$y = "bug!";
	var_dump($x);
	print "<br>\n$x";
}

$i =& f1();
$j =& f1();
f2();
?>

The output that I get is:
NULL
bug!

So, after 2 references to uninitialized variables, everything behaves unpredictably.

It is easy to see how this situation could occur in "real" code.  In our case, we were building objects from a database select query.  We were iterating through the rows and putting data in $a[].  When there were no rows, $a was never initialized, but it was extremely difficult to isolate the problem because other functions, across many files, were misbehaving due to this bug.

[2003-03-25 17:41 UTC] jseverson at myersinternet dot com

Same as bug <a href="http://bugs.php.net/bug.php?id=20583">Bug 20583</a>

I've posted a list of all bug reports I've found that seem to be related to this same php bug, 20583.

[2003-07-29 12:57 UTC] iliaa@php.net

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

[2003-07-30 11:53 UTC] sniper@php.net

This will most likely be fixed in PHP 5 earliest.