Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
| From: | josiecki at silvercube dot pl | Date: | Thu, 15 Dec 2011 14:42:35 +0000 |
| Subject: | Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-165883@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=45735&edit=1
ID: 45735
Comment by: josiecki at silvercube dot pl
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:
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...
Previous Comments:
------------------------------------------------------------------------
[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, [ ])
------------------------------------------------------------------------
[2008-08-07 08:28:20] derick@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?
------------------------------------------------------------------------
[2008-08-06 17:40:08] felipe@php.net
That is known PCRE behavior.
See: http://manpages.courier-mta.org/htmlman3/pcrestack.3.html
------------------------------------------------------------------------
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