php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #33151 [PCRE] Implement a sane behavior when PCRE runs out of stack space
Submitted: 2005-05-26 14:17 UTC Modified: 2006-06-11 12:19 UTC
From: mikko dot rantalainen at peda dot net Assigned: andrei (profile)
Status: Closed Package: Feature/Change Request
PHP Version: Any OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mikko dot rantalainen at peda dot net
New email:
PHP Version: OS:

 

 [2005-05-26 14:17 UTC] 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.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-06-11 12:19 UTC] nlopess@php.net
PHP 5.2 already features this. (the documentation should be online soon)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 16:01:28 2024 UTC