Bug 133891
| Summary: | php Segmentation fault in preg_match with about 16000 bytes data | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Doncho Gunchev <dgunchev> |
| Component: | php | Assignee: | Joe Orton <jorton> |
| Status: | CLOSED CANTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | mattdm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-30 15:04:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Yes, pcre handles such expressions using function recursion so it exhausts the stack for a long input string, we saw this elsewhere recently. 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 :(
Yes, many bugs upstream have been filed upstream and are usually closed with "it's a pcre problem". http://bugs.php.net/bug.php?id=24460 http://bugs.php.net/bug.php?id=26171 http://bugs.php.net/bug.php?id=27070 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? 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! 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 report. 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. 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). |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040923 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): php-4.3.8-11 How reproducible: Always 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: #!/bin/bash # somewhere around 13495 bytes dd if=/dev/zero bs=1 count=16000 > crash.html cat << EOF > crash.php #!/usr/bin/php -q <?php set_time_limit(0); // Don't die today \$f = 'crash.html'; \$h = fopen(\$f, 'r'); \$d = fread(\$h, 1024 * 16000); fclose(\$h); if (! preg_match('/(.|\n)*/', \$d, \$a)) { die("Can not parse document!\n"); } else { echo("Match: '{\$a[1]}'\n"); } ?> EOF chmod a+x crash.php ./crash.php PS: adjust php.ini to allow more than 8MB mem usage (16/32). I tested this with FC1 and FC3-t2.