Bug #69864 [Ver]: Segfault in preg_replace_callback

Edit report at https://bugs.php.net/bug.php?id=69864&edit=1 ID: 69864 Updated by: ab@php.net Reported by: james dot h dot cracknell at gmail dot com Summary: Segfault in preg_replace_callback Status: Verified Type: Bug Package: PCRE related Operating System: Windows Server 2008 R2 PHP Version: 7.0.0alpha1 Assigned To: cmb Block user comment: N Private report: N New Comment: Ah, as from the patch, it should be pcre_cache_entry *pce = (pcre_cache_entry *) Z_PTR_P(data); but it probably won't fix the issue, just to mention. Thanks. Previous Comments: ------------------------------------------------------------------------ [2015-06-19 14:51:49] ab@php.net i meant "using a crashy snippet without any patch" - so that's the plain situation where you see all the errors ... :) Thanks. ------------------------------------------------------------------------ [2015-06-19 14:50:35] ab@php.net Hi Christoph, nope, HashTable is unlikely to cause an issue. It's a very core API which is used everywhere, so it's probably not causing this. But if you're using the snippet from @james which is already know to cause crash, clear there'll be such kinds of errors. So don't even need to mention that. And the cause of it, as reported and also confirmed by yourself, is that the cache is freed without check which causes accesses to the invalid memory. Except you've found out something new ;) Thanks. ------------------------------------------------------------------------ [2015-06-19 13:40:36] cmb@php.net Have you tried without the patch, Anatol? I get very similar results before having applied the patch. Nearly all of the warnings seem to be caused by php_free_pcre_cache(). Storing non-zvals in a HashTable[1] might not work reliably? [1] <http://lxr.php.net/xref/PHP_TRUNK/ext/pcre/php_pcre.c#492> ------------------------------------------------------------------------ [2015-06-18 20:31:09] ab@php.net I can see many errors like this with the new patch and the snippet @james posted earlier ==54386== Invalid read of size 1 ==54386== at 0x409ED6D: ??? ==54386== by 0xD801E77: ??? ==54386== by 0xFFEFF3D8F: ??? ==54386== Address 0xe699641 is 65 bytes inside a block of size 264 free'd ==54386== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==54386== by 0x4E14A2: free_read_only_data (pcre_jit_compile.c:2139) ==54386== by 0x502C4A: _pcre_jit_free (pcre_jit_compile.c:10532) ==54386== by 0x4D311E: pcre_free_study (pcre_study.c:1672) ==54386== by 0x503C79: php_free_pcre_cache (php_pcre.c:96) ==54386== by 0xA3DF4C: _zend_hash_del_el_ex (zend_hash.c:935) ==54386== by 0xA3E032: _zend_hash_del_el (zend_hash.c:959) ==54386== by 0xA3F4DD: zend_hash_apply_with_argument (zend_hash.c:1463) ==54386== by 0x504D30: pcre_get_compiled_regex_cache (php_pcre.c:450) ==54386== by 0x5073D7: php_pcre_replace (php_pcre.c:1028) ==54386== by 0x508322: php_replace_in_subject (php_pcre.c:1361) ==54386== by 0x508976: preg_replace_impl (php_pcre.c:1422) But in general - yep, in this case it's probably better to concentrate to fix master first, and then to backport into 5.6 when we see it stable in master. Not sure what's wrong with refcounts, probably better just to debug it. Thanks. ------------------------------------------------------------------------ [2015-06-18 14:06:42] kalle@php.net Fix assignee (was lost after Rasmus' comment) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69864 -- Edit this bug report at https://bugs.php.net/bug.php?id=69864&edit=1