php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31704 pointer error in var_unserializer.c?
Submitted: 2005-01-26 16:38 UTC Modified: 2005-01-27 10:59 UTC
From: frode at coretrek dot no Assigned:
Status: Closed Package: Strings related
PHP Version: 4.3.10 OS: FreeBSD 4.10
Private report: No CVE-ID: None
 [2005-01-26 16:38 UTC] frode at coretrek dot no
Description:
------------
I've been having problems with php segfaulting randomly when using the FreeBSD ports-build of php, with errors that do not appear to occur when using the "php-4.3.10.tar.bz" vanilla tarball. While browsing FreeBSD's patches for php-4.3.10, I noticed the following file:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php4/files/patch-ext%3a%3astandard%3a%3avar_unserializer.c
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/php4/files/patch-ext%3a%3astandard%3a%3avar_unserializer.c?rev=1.1&content-type=text/plain

which appears to be based on, among other patches, the following commit:

http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.c?r1=1.48&r2=1.49&ty=u

Notice that "old_data" is changed from a "zval*" to a "zval**". Looking at the "full picture" in the latest version of this file at:

http://cvs.php.net/co.php/php-src/ext/standard/var_unserializer.c?r=1.18.4.18

I can see that "(void**)&old_data" is passed to zend_hash_index_find.

My C knowledge is rusty at best, but doesn't this result in an "zval***" being cast into a "void**", i.e. wrong number of indirections? 

I'd appreciate it if someone more familiar with the PHP sourcecode could have a look at this and determine if there is a bug here.



Reproduce code:
---------------
N/A

Expected result:
----------------
N/A

Actual result:
--------------
N/A

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-26 23:03 UTC] sesser@php.net
The code is correct in that area.

If you are using sessions your segfault could be cause because FreeBSD does not use

http://cvs.php.net/diff.php/php-src/ext/session/session.c?r1=1.336.2.48&r2=1.336.2.49&ty=u

without this fix it is possible that the rearrangement of unserialize() triggers the bug in the session module.

If this does not fix the problem please give a full backtrace. Because even if the code segfaults in unserialize() the crash could be cause because it was previously called in an not 100% correct way. 
 [2005-01-27 08:47 UTC] frode at coretrek dot no
I tried using the snaps.php.net STABLE tarball, and it seems to work. But then again, I can't get the FreeBSD-ports-build to crash either anymore. :-/

I think you can close this bug since I'm unable to reproduce any errors right now. If I do manage to capture any segfaults with gdb, I'll post back with the backtraces.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri May 17 18:01:33 2024 UTC