Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735edit=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;, 200)); [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 - 1.38.2.3.2.10.2.3 +++ ext/pcre/config0.m4 7 Aug 2008 11:25:39 - @@ -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=45735edit=1
Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735edit=1 ID: 45735 Comment by: johnston dot joshua 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: I agree that something needs to be done about this bug on the php side that doesn't involve custom compiling pcre. In my case way back in '08, I found that the solution was misuse of capturing subpatterns. I was using () for grouping even though I did not need to match subpatterns. In reality I should have been using (:?) which solved my issue. Previous Comments: [2013-04-12 18:40:49] josh dot adell at gmail dot com 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. [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;, 200)); 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=45735edit=1
Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735edit=1 ID: 45735 Comment by: michael at writhem 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: why is this status not a bug? Previous Comments: [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;, 200)); [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 - 1.38.2.3.2.10.2.3 +++ ext/pcre/config0.m4 7 Aug 2008 11:25:39 - @@ -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 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=45735edit=1
Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735edit=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;, 200)); [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 - 1.38.2.3.2.10.2.3 +++ ext/pcre/config0.m4 7 Aug 2008 11:25:39 - @@ -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=45735edit=1
Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735edit=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;, 200)); [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 - 1.38.2.3.2.10.2.3 +++ ext/pcre/config0.m4 7 Aug 2008 11:25:39 - @@ -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? [2008-08-06 17:40:08] fel...@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=45735edit=1
