From: mikko dot rantalainen at peda dot net Operating system: Linux PHP version: 5.0.4 PHP Bug Type: PCRE related Bug description: [RFE] Implement a sane behavior when PCRE runs out of stack space
Description: ------------ PHP already has a number of bugs reported (http://bugs.php.net/search.php?search_for=crash+segmentation&boolean=0&limit=30&order_by=&direction=ASC&cmd=display&status=All&bug_type%5B%5D=PCRE+related) because of PCRE related crashes that are result of PCRE using heavy recursion with some patterns. Making always sure that both pattern and input string are always safe when using functions implemented with PCRE is really hard from PHP code because the most often hit limit is too small stack and PCRE is really the only part of the code that has knowledge to compute the stack usage. PHP already has it's own copy of PCRE and I'm requesting that that copy is modified so that PCRE is aware of stack usage and returns an error if computing the result would result in stack overflow and possible segmentation fault. If that is considered to be too much of work, PHP should at least put a hard limit on recursion as described in PCRE documentation: http://www.pcre.org/pcre.txt: "LIMITING PCRE RESOURCE USAGE ...a limit can be placed on the resources used by a single call to pcre_exec(). The limit can be changed at run time, as described in the pcreapi documentation..." Another way to workaround this problem is described by jorton at php.net in bug #28461: "One way PHP could mitigate the issue is to to set the match_limit field in the pcre_extra structure which puts a limit on the depth of the stack recursion." (I'm not sure if this is the actual implementation of above note?) Rationale: preg_* functions are often used for input validation just like in Perl. However, it cannot be safely used for that purpose because of all these bugs that result in stack overflows and/or segmentation faults. Increasing stack size cannot be as a workaround because stack usage seems to be exponential. (Resulting segmentation faults inside an Apache module are real pain in the ass to debug, too.) Reproduce code: --------------- <?php preg_match('/(ab?)+/', str_repeat('a', 100000)); ?> Expected result: ---------------- preg_match() should return true because the test string passes the test that it's composed of a's possibly followed by b's. Actual result: -------------- Crash. Isn't limited to PHP 5.x. I wouldn't expect 100KB of text to be too much because I've set my stack to 8192KB (more than 80x the size of the string to search) but I still get segmentation fault. Increase the counter "100000" to reproduce the crash if you have huge stack. -- Edit bug report at http://bugs.php.net/?id=33151&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33151&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33151&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33151&r=trysnapshot51 Fixed in CVS: http://bugs.php.net/fix.php?id=33151&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=33151&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33151&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33151&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33151&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33151&r=support Expected behavior: http://bugs.php.net/fix.php?id=33151&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33151&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33151&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=33151&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33151&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=33151&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33151&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33151&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33151&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33151&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33151&r=mysqlcfg
