Bug 133891 - php Segmentation fault in preg_match with about 16000 bytes data
Summary: php Segmentation fault in preg_match with about 16000 bytes data
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-28 10:35 UTC by Doncho Gunchev
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2006-10-30 15:04:18 UTC

Attachments (Terms of Use)

Description Doncho Gunchev 2004-09-28 10:35:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
    PHP's preg_match segfaults with more than about 13495 (random, but
with 16000 - always).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install FC1/FC3t2 (haven't tested others yet)
2. do preg_match('/(.|\n)*/', $d, $a) with $d > 16000 bytes

Actual Results:  Segmentation fault

Expected Results:  Anything else :)

Additional info:

here's my test script:

# somewhere around 13495 bytes
dd if=/dev/zero bs=1 count=16000 > crash.html
cat << EOF > crash.php
#!/usr/bin/php -q
set_time_limit(0);      // Don't die today

\$f = 'crash.html';
\$h = fopen(\$f, 'r');
\$d = fread(\$h, 1024 * 16000);
if (! preg_match('/(.|\n)*/', \$d, \$a)) {
    die("Can not parse document!\n");
} else {
    echo("Match: '{\$a[1]}'\n");
chmod a+x crash.php

PS: adjust php.ini to allow more than 8MB mem usage (16/32).
I tested this with FC1 and FC3-t2.

Comment 1 Joe Orton 2004-09-28 11:58:05 UTC
Yes, pcre handles such expressions using function recursion so it
exhausts the stack for a long input string, we saw this elsewhere

Comment 2 Doncho Gunchev 2004-09-28 12:43:20 UTC
    Is there pcre bug (I can't find it), so this bug can be marked as
depending on it?
    If there's no such bug report can someone fill it (or should I),
because there are other programs that use this library? Postfix with
pcre enabled can be crashed if it is parsing big message body with
pcre for example. Looks serious :(

Comment 3 Joe Orton 2004-10-07 16:16:40 UTC
Yes, many bugs upstream have been filed upstream and are usually
closed with "it's a pcre problem".


Comment 4 Doncho Gunchev 2004-10-11 21:16:14 UTC
Yes, and sadly, I should report that even pcre-5.0 (which changes
license to BSD and should fix some UTF-8 related bugs) does not help.
Is there any alternative? Can perl's regex engine be used instead?

Comment 5 Matthew Miller 2006-07-10 23:22:37 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 6 John Thacker 2006-10-30 15:04:18 UTC
Closing per lack of response to previous request for information.  This bug was
originally filed against FC3 and has remained in NEEDINFO state for quite some
time.  Many packages and bugfixes have been made since the last substantive bug

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

Comment 7 Doncho Gunchev 2007-03-01 22:46:44 UTC
The bug is still present in FC6, but it's not RHEL/FC specific, maybe not so
critical and would be better to be fixed upstream...
If someone is interested and can help - please reopen(mail me to).

Note You need to log in before you can comment on or make changes to this bug.