Edit report at https://bugs.php.net/bug.php?id=63369&edit=1
ID: 63369
Updated by: tony2...@php.net
Reported by: tony2...@php.net
Summary: (un)serialize() leaves dangling pointers, causes
crashes
-Status: Open
+Status: Closed
Type: Bug
Package: Reproducible crash
Operating System: *
PHP Version: 5.4Git-2012-10-26 (Git)
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f2bffdc2e48174e38a059d425953e8b1c08dd4bf
Log: fix bug #63369
Previous Comments:
------------------------------------------------------------------------
[2012-10-26 12:24:03] tony2...@php.net
The following patch has been added/updated:
Patch Name: the-patch
Revision: 1351254242
URL:
https://bugs.php.net/patch-display.php?bug=63369&patch=the-patch&revision=1351254242
------------------------------------------------------------------------
[2012-10-26 12:23:16] tony2...@php.net
Description:
------------
When a fatal error happens in a __sleep/__wakeup function, BG(serialize) and
BG(unserialize) contents is left intact and the next request will get those
pointers
again, even though at that moment they are already freed by Zend memory manager
during request shutdown.
If you're lucky, there is a chance you'll reuse them, which causes immediate
crash.
The attached scripts demonstrates the problem with serialize() and I'm kinda
lazy to
do the same for unserialize(), especially taking into account that the patch is
extremely simple.
Test script:
---------------
class bar1 {
function __sleep() {
foo();
}
}
class foo1 {
function __sleep() {
var_dump(serialize(array("test", "1", 234)));
var_dump(serialize(new bar1));
}
}
$o = new foo1;
var_dump(unserialize('O:8:"stdclass":0:{}')); //to clear BG(serialize_lock)
var_dump(serialize($o));
Expected result:
----------------
.
Actual result:
--------------
.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=63369&edit=1
