Edit report at https://bugs.php.net/bug.php?id=45546&edit=1
ID: 45546
Updated by: ras...@php.net
Reported by: kaiser at macbureau dot de
Summary: PCRE with utf8 kill apache childprocess
-Status: No Feedback
+Status: Wont fix
Type: Bug
Package: PCRE related
Operating System: FreeBSD 7
PHP Version: 5.2.6
Block user comment: N
Private report: N
New Comment:
There isn't a whole lot we can do about this. PCRE internally calls match()
recursively in some circumstances. We have the pcre.recursion_limit setting to
prevent pcre from eating all available stack for really nasty regular
expressions, but depending on the expression and how you set that limit you can
still write a regex that will cause pcre to eat your entire stack. For example,
taking one of the reproducing scripts in this report and modifying it slightly
to pass in the number of a's in $str:
<?php
$str = str_repeat('a', $argv[1]);
$utf8 = (preg_match("/^([\x09\x0A\x0D\x20-\x7E]|[\xC2-\xDF][\x80-
\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}|
\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x90-\xBF][\x80-\xBF]{2}|[\xF1-\xF3][\x80-\xBF]
{3}|\xF4[\x80-\x8F][\x80-\xBF]{2})*$/", $str)) ? "yes
" : "no";
echo $utf8."\n";
if (preg_last_error() == PREG_RECURSION_LIMIT_ERROR) {
print 'Recursion limit was exhausted!';
}
And then running it with various lengths and recursion limits:
% php -d pcre.recursion_limit=1000 g 100
yes
So, with a recursion limit of 1000 and just 100 a's we are fine. But, increase
it to 1000 a's and we get:
% php -d pcre.recursion_limit=1000 g 1000
no
Backtrack limit was exhausted!
At a certain level you will be able to smash your entire stack if you set your
limit high enough:
% php -d pcre.recursion_limit=100000 g 10000
Segmentation fault (core dumped)
There are some really really slow checks we can do to detect this, but we would
have to run these for every regex and we don't feel the performance hit is
worth
it. There are usually ways to rewrite the regex that doesn't need to recurse
indefinitely like this.
If someone has a decent way to fix this that doesn't slow down every match by a
lot, please send us a patch, but until then I would suggest fixing your regexes.
This is either a "Won't fix" or "Not a bug" although neither really describe
the
situation. It is more like a "Can't fix in a sane way" situation.
Previous Comments:
------------------------------------------------------------------------
[2012-06-29 04:42:34] mihalych at vsepofigu dot ru
Status of this bug is still "No Feedback". What kind of feedback is needed to
fix this issue?
------------------------------------------------------------------------
[2011-06-30 23:10:53] toreador at gmail dot com
is it fixed on 5.4?
------------------------------------------------------------------------
[2011-05-19 12:29:37] chris at cretaforce dot gr
I confirm that the problem still exist:
FreeBSD 7.4
Pcre 8.12
PHP 5.3.6
Lighttpd 1.4.28
------------------------------------------------------------------------
[2011-03-10 01:01:11] toreador at gmail dot com
Problem still exist.
Freebsd 8.2
Pcre 8.12
PHP 5.3.5
Apache 2.2.17
------------------------------------------------------------------------
[2010-10-15 21:44:50] sergio at gruposinternet dot com dot br
It seems that setting pcre.recursion_limit to 1700 can be used as workaround,
but be warned to check for error conditions as stated by the documentation at
http://www.php.net/preg_match
------------------------------------------------------------------------
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=45546
--
Edit this bug report at https://bugs.php.net/bug.php?id=45546&edit=1
