ID: 33151 Updated by: [EMAIL PROTECTED] Reported By: mikko dot rantalainen at peda dot net -Status: Bogus +Status: Assigned Bug Type: PCRE related Operating System: Linux PHP Version: 5.0.4 -Assigned To: +Assigned To: andrei
Previous Comments: ------------------------------------------------------------------------ [2005-05-26 19:39:44] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Repeating will not make us fix any bugs any faster, quite the contrary. ------------------------------------------------------------------------ [2005-05-26 14:17:39] mikko dot rantalainen at peda dot net 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 this bug report at http://bugs.php.net/?id=33151&edit=1
