php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51265 Segfault because of wrong memory allocation
Submitted: 2010-03-10 18:43 UTC Modified: 2013-02-18 00:34 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: gotwig at papaya-cms dot com Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 5.2SVN-2010-03-10 (SVN) OS: Debian GNU/Linux 4.0
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: gotwig at papaya-cms dot com
New email:
PHP Version: OS:

 

 [2010-03-10 18:43 UTC] gotwig at papaya-cms dot com
Description:
------------
Hallo,

I have found a bug in _emalloc logic where an allocation returns a pointer to a cached block smaller than requested; when this block is used some memory after that goes corrupted and we get a segfault.
The problem is reproducible with our project code, that is a version of papaya cms, but I am not able to reconstruct all circumstances with an example script to send you, sorry. I am debugging it itself, but need perhaps some help from you to understand how exact does memory allocation works here and where will be such one error possible: such a wrong pointer comes from the case on Lines 1778...1790 in zend_alloc.c :

if (EXPECTED(heap->cache[index] != NULL)) { ...

also, that is a previously freed cached block, but I have actually no idea where should I look any further. Please, give me some advice.

My configuration:

PHP Version from http://svn.php.net/repository/php/php-src/branches/PHP_5_2
Revision: 296029
compiled with ./configure --disable-cli --disable-cgi --disable-fastcgi --with-apxs2=/usr/bin/apxs2 --enable-debug --with-mysql --with-xsl
OS: Debian GNU/Linux 4.0

I have also tested this problem on a build from actually 5.3 branch, but was not able to reproduce, perhaps because of many changes in another logic there. But if this bug really comes from _zend_mm_alloc_int function their code did not changed in 5.3 and the problem may also occur there.

The bug is not critical for our company, we have found a workaround where this will not be triggered any more, but this is of course not a solution an I want to repair it at the source.


Thank you in advance,

Viktor Gotwig.

Actual result:
--------------
My Debuging:

br /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:1761
#0  _zend_mm_alloc_int (heap=0x81de2a0, size=41) at /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:1761
#1  0xb767fbb5 in zend_is_callable_ex (callable=0xb6c420cc, check_flags=0, callable_name=0xbf87c2f4, callable_name_len=0xbf87c278, ce_ptr=0xbf87c274,
    fptr_ptr=0xbf87c26c, zobj_ptr_ptr=0xbf87c268) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2287
#2  0xb767ff97 in zend_is_callable (callable=0xb6c420cc, check_flags=0, callable_name=0xbf87c2f4) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363
#3  0xb74bd2a4 in preg_replace_impl (ht=3, return_value=0xb6c42290, return_value_ptr=<value optimized out>, this_ptr=0x0, return_value_used=1,
    is_callable_replace=1 '\001') at /data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319

(gdb) x/21wx 0x81de2a0
0x81de2a0:      0x00000001      0x00000002      0x00025000      0x00040000
0x81de2b0:      0x00200000      0xb6b89008      0x0818b4f0      0x00340000
0x81de2c0:      0x00340000      0x08000000      0x00306030      0x0030c124
0x81de2d0:      0x00002000      0xb6fcd018      0x00000000      0x00000000
0x81de2e0:      0x00001bfc      0xb6c2b22c      0xb6c41b10      0x00000000
0x81de2f0:      0xb6c41f50

until /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:1934

(gdb) p/x $eax
$8 = 0xb6c4207c
(gdb) x/21wx 0x81de2a0
0x81de2a0:      0x00000001      0x00000002      0x00025000      0x00040000
0x81de2b0:      0x00200000      0xb6b89008      0x0818b4f0      0x00340000
0x81de2c0:      0x00340000      0x08000000      0x00306030      0x0030c124
0x81de2d0:      0x00002000      0xb6fcd018      0x00000000      0x00000000
0x81de2e0:      0x00001bc8      0xb6c2b22c      0xb6c41b10      0x00000000
0x81de2f0:      0xb6c41f50

(gdb) x/20wx $eax-8
0xb6c42074:     0x00000035      0x00000019      0x00000000      0x74556179
0xb6c42084:     0x74536c69      0x676e6972      0x38667455      0x6e653a3a
0xb6c42094:     0x65727573      0x72616843      0x6c6c6143      0x6b636162
0xb6c420a4:     0x5c2d3000      0x0000001d      0x00000035      0x00000000
0xb6c420b4:     0x68636572      0x61637261      0x61626c6c      0x20006b63
(gdb) x/s 0xb6c42080
0xb6c42080:      "yaUtilStringUtf8::ensureCharCallback"



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-03-12 14:45 UTC] gotwig at papaya-cms dot com
Hallo,

my assumption about a wrong sized block allocation has not confirmed, I have the source of the problem now: 
- it occurs in preg_replace_impl function, 
- our php code use preg_replace_callback with a static callback to a non-static object method,
- this raise an E_STRICT warning where an user defined error handler will be called,
- this call reallocates argument stack where some pointers to the previous argument stack frame are already saved in preg_replace_impl and will be used a bit later.

Our PHP code likes as following:

class PapayaUtilStringUtf8 {
...
preg_replace_callback(
      $pattern, 
      array('PapayaUtilStringUtf8', 'ensureCharCallback'),
      (string)$string
    );
...
  function ensureCharCallback($charMatch) {
  ...
  }

}

Actual backtrace from reallocation call, where p=0xb70318b0 is argument_stack :

#0  _zend_mm_realloc_int (heap=0x81de2a0, p=0xb70318b0, size=516) at /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:2005          
#1  0xb76d02e9 in zend_call_function (fci=0xbfad9d84, fci_cache=0x0) at /data/extern/php_svn/php-src-5.2/Zend/zend_ptr_stack.h:99     
#2  0xb76d191e in call_user_function_ex (function_table=0x812b088, object_pp=0x0, function_name=0xb6bedd0c, retval_ptr_ptr=0xbfad9e00, param_count=5, params=0xb6bed450, 
    no_separation=1, symbol_table=0x0) at /data/extern/php_svn/php-src-5.2/Zend/zend_execute_API.c:640                                                                   
#3  0xb76dbfe8 in zend_error (type=2048, format=0xb780ba78 "Non-static method %s::%s() cannot be called statically") at /data/extern/php_svn/php-src-5.2/Zend/zend.c:1041
#4  0xb76e18fe in zend_is_callable_check_func (check_flags=<value optimized out>, zobj_ptr_ptr=0xbfad9eb8, ce_org=0xb6d1dda0, callable=0xb6b349f8, ce_ptr=0xbfad9ec4,    
    fptr_ptr=0xbfad9ebc) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2204                                                                                        
#5  0xb76e1cac in zend_is_callable_ex (callable=0xb6b349e0, check_flags=<value optimized out>, callable_name=0xbfad9f44, callable_name_len=0x0, ce_ptr=0xbfad9ec4,       
    fptr_ptr=0xbfad9ebc, zobj_ptr_ptr=0xbfad9eb8) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2332                                                               
#6  0xb76e1f97 in zend_is_callable (callable=0xb6b349e0, check_flags=0, callable_name=0xbfad9f44) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363               
#7  0xb751f2a4 in preg_replace_impl (ht=3, return_value=0xb6b34cac, return_value_ptr=<value optimized out>, this_ptr=0x0, return_value_used=1,
    is_callable_replace=1 '\001') at /data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319
 [2010-03-12 16:03 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2010-03-12 16:03 UTC] pajoye@php.net
Do you have a script to reproduce this problem?
 [2010-03-12 16:25 UTC] gotwig at papaya-cms dot com
sorry, I have actually no idea how to exactly reproduce a stack reallocation inside of preg_replace_callback with a custom script to help you. I must think about, perhaps some days later.
 [2010-06-08 14:58 UTC] tony2001@php.net
-Status: Open +Status: Feedback
 [2010-06-08 14:58 UTC] tony2001@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2013-02-18 00:34 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 "Open". Thank you.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri Aug 19 11:05:45 2022 UTC