php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #41050 Segmentation fault using preg_match (any PCRE matching)
Submitted: 2007-04-11 10:51 UTC Modified: 2007-04-20 11:04 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: legolas558 at users dot sourceforge dot net Assigned:
Status: Not a bug Package: PCRE related
PHP Version: 4.4.6 OS: Windows XP SP2
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: legolas558 at users dot sourceforge dot net
New email:
PHP Version: OS:

 

 [2007-04-11 10:51 UTC] legolas558 at users dot sourceforge dot net
Description:
------------
I have tested the below script with PHP 4.4.4.4 and there was no problem; now with PHP 4.4.6 there is a crash (probably a segmentation fault) and a server error (500) is returned. I could not provide a win32 backtrace however you can easily generate it using the testcase.

Reproduce code:
---------------
<?php
// by legolas558

$regex = '/(insert|drop|create|select|delete|update)([^;\']*('."('[^']*')+".')?)*(;|$)/i';

$sql = 'SELECT * FROM #__components';

//$sql = ''; // does not cause error

if (preg_match($regex,$sql, $m)) echo 'matched';
else echo 'not matched';

?>

Expected result:
----------------
matched

Actual result:
--------------
CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-04-11 11:19 UTC] legolas558 at users dot sourceforge dot net
Ok, I am going to post the results within a few minutes
 [2007-04-11 11:24 UTC] legolas558 at users dot sourceforge dot net
I have tested with the current v4.4.7 and there is the same problem; I have seen the same bug marked as "bogus" for other OSes since looks like being a PCRE library bug.

I have clues that this bug breaks A LOT of different PHP applications
 [2007-04-11 11:27 UTC] derick@php.net
It's a stack overflow in the pcre library... so how can we fix this?
 [2007-04-11 11:29 UTC] legolas558 at users dot sourceforge dot net
Would it be viable to compile with an older PCRE library?

And, is the PCRE development team addressing the issue of their most recent release?
 [2007-04-11 11:31 UTC] derick@php.net
I've no idea if they are looking at this. And no, compiling with an older lib is not possible as the new version has plenty of bug fixes as well.
 [2007-04-11 11:39 UTC] legolas558 at users dot sourceforge dot net
I understand.

I will try to contact the PCRE mantainer, and if he is not working on the issue I will try to get my hands dirt and patch it myself. If I end up with a patch for the PCRE library I hope it will be accepted in PHP's  CVS tree

If the bug is not reproducible out of PHP (with a C testcase, for example) there are high chances that it is a PHP-related bug.

I will now test the bug out of PHP and see if it still happens.
 [2007-04-11 12:00 UTC] legolas558 at users dot sourceforge dot net
I have tested the subject and regex in a C snippet and the segmentation fault does not happen

So the bug is someway related to PHP's usage (maybe initialization and reset?) of the PCRE library

More tests would be needed, of course
 [2007-04-11 14:01 UTC] tony2001@php.net
We can't fix PCRE.
 [2007-04-11 14:08 UTC] legolas558 at users dot sourceforge dot net
Of course.

But did you check if the bug(s) also happens out of PHP? e.g. if it is ONLY a PCRE bug?
 [2007-04-16 15:34 UTC] legolas558 at users dot sourceforge dot net
I found a workaround for my own problem, maybe it will help other users or help individuating the bug.

<?php
// by legolas558

$regex = "(?i:begin|start)\\s+([^']*('[^']*')*)*";

$old_php_regex = "/".$regex."/";

// notice the greedy/ungreedy change which actually works around the segmentation fault
$bug41050_regex = "/".$regex."?/";

// test case
$subject = "begin\nnon string 'string' other non string";

// will work on any PHP - also the latest versions with PCRE7
preg_match_all($bug41050_regex, $subject, $m);

echo '<pre>';var_dump($m);echo '</pre>'; unset($m);

// will cause a segmentation fault (and so a 500 server error) if used on PHP versions compiled with PCRE7
// preg_match_all($old_php_regex, $subject, $m);

echo '<pre>';var_dump($m);echo '</pre>';

?>
 [2007-04-20 10:55 UTC] legolas558 at users dot sourceforge dot net
G.Baconniere kindly provided a patch to downgrade PHP 4.4.6's internal PCRE7 to PCRE6.6

http://www.infomaniak.ch/php4/php-4.4.6-downgrade_pcre.patch

I have not tested it, however the author is trusted.

Note: use at your own risk, you will not take advantage of the bugfixes in PCRE7
 [2007-04-20 11:04 UTC] tony2001@php.net
You don't have to apply any patches in order to build PHP with external PCRE (if you don't like the bundled version).
Use --with-pcre-regex=DIR option to do that.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 14 18:01:27 2024 UTC