Edit report at https://bugs.php.net/bug.php?id=45735&edit=1
ID: 45735
Comment by: vojtech dot kurka at gmail dot com
Reported by: johnston dot joshua at gmail dot com
Summary: preg_match fails with Segmentation Fault on
capturing subpattern
Status: Bogus
Type: Bug
Package: PCRE related
Operating System: *
PHP Version: 5.2CVS, 5.3CVS, 6CVS (2008-08-06)
Block user comment: N
Private report: N
New Comment:
We have hit this bug today on 5.3.8, just sending 70KB variable as an input to
preg_match_all().
Please fix this, it took us quite a lot of time to find the root cause. This
should never cause a segfault. If the preg_match_all() function would throw a
standard PHP error/warning, we would find the problem immeadiately. Debugging
such problems is just a waste of time, this bugreport is more than 3 years old.
Previous Comments:
------------------------------------------------------------------------
[2011-12-15 14:42:35] josiecki at silvercube dot pl
Why is this bug status set to "Bogus"? Seems to be unsolved since over three
years, and I haven't found a single PHP installation that would not be
vulnerable to this, including quite new 5.3.8 installation...
------------------------------------------------------------------------
[2008-08-07 13:44:55] johnston dot joshua at gmail dot com
Just for my own personal knowledge, is it the capturing pattern the part that
causes the recursion?
If I remove the () part of the pattern I can keep adding 0's to the below code
I can trigger a php memory error but no seg fault.
jjohnston:~$ php -r 'preg_match("/http:\/\/.+\.ru/i",
str_repeat("http://google.ru";, 2000000));
------------------------------------------------------------------------
[2008-08-07 11:27:29] lbarn...@php.net
I seen that PCRE has a NO_RECURSE flag to avoid the recursion in
match() (described in pcre_exec.c).
Defining NO_RECURSE at compile time avoids this problem :)
diff -u -r1.38.2.3.2.10.2.3 config0.m4
--- ext/pcre/config0.m4 2 Jun 2008 14:12:20 -0000
1.38.2.3.2.10.2.3
+++ ext/pcre/config0.m4 7 Aug 2008 11:25:39 -0000
@@ -59,7 +59,7 @@
pcrelib/pcre_ord2utf8.c
pcrelib/pcre_refcount.c pcrelib/pcre_study.c \
pcrelib/pcre_tables.c
pcrelib/pcre_try_flipped.c pcrelib/pcre_valid_utf8.c \
pcrelib/pcre_version.c
pcrelib/pcre_xclass.c"
- PHP_NEW_EXTENSION(pcre, $pcrelib_sources php_pcre.c, no,,-
+ PHP_NEW_EXTENSION(pcre, $pcrelib_sources php_pcre.c, no,,-
PHP_ADD_BUILD_DIR($ext_builddir/pcrelib)
PHP_INSTALL_HEADERS([ext/pcre], [php_pcre.h pcrelib/])
AC_DEFINE(HAVE_BUNDLED_PCRE, 1, [ ])
------------------------------------------------------------------------
[2008-08-07 08:28:20] der...@php.net
AFAIK only be using a non-stack based evaluator (pcre_dfa_exec)... which is not
compatible with the perl regular expressions, see the description at
http://manpages.courier-mta.org/htmlman3/pcre_dfa_exec.3.html
------------------------------------------------------------------------
[2008-08-06 17:47:50] johnston dot joshua at gmail dot com
I understand it is a known pcre behavior but does that mean it is ok to let
pcre trigger a segmentation fault? Is there no possible way to handle this
failure gracefully?
------------------------------------------------------------------------
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=45735
--
Edit this bug report at https://bugs.php.net/bug.php?id=45735&edit=1
