Edit report at https://bugs.php.net/bug.php?id=45735&edit=1
ID: 45735
Comment by: josh dot adell at gmail dot com
Reported by: johnston dot joshua at gmail dot com
Summary: preg_match fails with Segmentation Fault on
capturing subpattern
Status: Not a bug
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:
Just hit this bug today as well. It would be nice if PHP handled this more
gracefully by triggering an error or warning instead of segfaulting.
Previous Comments:
------------------------------------------------------------------------
[2013-04-11 16:35:34] michael at writhem dot com
why is this status not a bug?
------------------------------------------------------------------------
[2011-12-23 13:09:46] vojtech dot kurka at gmail dot com
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.
------------------------------------------------------------------------
[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] lbarnaud@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, [ ])
------------------------------------------------------------------------
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