Debian Bug report logs -
#405067
php5-cli: Segfault after infinite recursion inside pcre - random memory corruption?
Reported by: Richard Atterer <atterer@debian.org>
Date: Sat, 30 Dec 2006 21:33:02 UTC
Severity: normal
Tags: confirmed, fixed-upstream, security, upstream, wontfix
Merged with 487283,
496795
Found in versions php5/5.2.0-8, php5/5.2.0-8+etch7, php5/5.2.6-1, php5/5.2.6-2
Fixed in version 5.3.3-7
Done: Ondřej Surý <ondrej@sury.org>
Bug is archived. No further changes may be made.
Forwarded to http://bugs.php.net/bug.php?id=40926
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org, Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>:
Bug#405067; Package php5.
(full text, mbox, link).
Acknowledgement sent to Richard Atterer <atterer@debian.org>:
New Bug report received and forwarded. Copy sent to Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Package: php5
Version: 5.2.0-8
Severity: important
Tags: security
Hello,
while developing my PHP application, I stumbled across PCRE usage which
crashes the PHP binary. After some trial and error, I was able to reduce
the problem to the attached piece of PHP code. I was able to reproduce the
segfault on 3 different machines running Debian, under php 5.2.0-8
(testing, 2 machines) and 4.3.10-18 (stable).
I also compiled versions of libpcre3 and php5-cli with debugging
information to get a stack trace. The topmost frames of the stack backtrace
follow at the end of this message. Inside libpcre3, the code recurses
through pcre_exec.c lines 677 and 1190 until the stack overflows.
Next, I tried to find out whether the crash is reproducible with a C
program. But while AFAICT the attached C program does the same as the code
in php-5.2.0/ext/pcre/php_pcre.c, no segfault happens. So maybe PHP
corrupts memory between compiling and executing the regex? I don't know!
:-/ Running "valgrind php5 php-5.2.0-8-segfault.php" doesn't output
anything which looks like a PCRE-related bug.
One more thing: I also tried to trim down the example further by reducing
the length of the subject string. This gives weird results: When some parts
of the input are removed, the crash becomes "unreliable" in that executing
"php5 php-5.2.0-8-segfault.php" will crash sometimes and sometimes it will
not.
I've "anonymized" my code by replacing alphabetic characters with "x",
that's why it looks so weird. :)
I'm tagging this "security" as this MAY potentially be a nasty bug which
might allow more than just segfaults. If you disagree, feel free to remove
the tag.
Cheers,
Richard
--
__ _
|_) /| Richard Atterer
| \/¯| http://geht.net.gibts.bei.atterer.net
¯ '` ¯
#8146 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9319a4, flags=<value optimized out>, rdepth=31) at ./pcre_exec.c:677
#8147 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9321a4,
flags=<value optimized out>, rdepth=30) at ./pcre_exec.c:1190
#8148 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9321a4, flags=<value optimized out>, rdepth=29) at ./pcre_exec.c:677
#8149 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9329a4,
flags=<value optimized out>, rdepth=28) at ./pcre_exec.c:1190
#8150 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9329a4, flags=<value optimized out>, rdepth=27) at ./pcre_exec.c:677
#8151 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9331a4,
flags=<value optimized out>, rdepth=26) at ./pcre_exec.c:1190
#8152 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9331a4, flags=<value optimized out>, rdepth=25) at ./pcre_exec.c:677
#8153 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9339a4,
---Type <return> to continue, or q <return> to quit---
flags=<value optimized out>, rdepth=24) at ./pcre_exec.c:1190
#8154 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9339a4, flags=<value optimized out>, rdepth=23) at ./pcre_exec.c:677
#8155 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9341a4,
flags=<value optimized out>, rdepth=22) at ./pcre_exec.c:1190
#8156 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9341a4, flags=<value optimized out>, rdepth=21) at ./pcre_exec.c:677
#8157 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9349a4,
flags=<value optimized out>, rdepth=20) at ./pcre_exec.c:1190
#8158 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9349a4, flags=<value optimized out>, rdepth=19) at ./pcre_exec.c:677
#8159 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9351a4,
flags=<value optimized out>, rdepth=18) at ./pcre_exec.c:1190
#8160 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9351a4, flags=<value optimized out>, rdepth=17) at ./pcre_exec.c:677
#8161 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9359a4,
flags=<value optimized out>, rdepth=16) at ./pcre_exec.c:1190
#8162 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9359a4, flags=<value optimized out>, rdepth=15) at ./pcre_exec.c:677
#8163 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9361a4,
flags=<value optimized out>, rdepth=14) at ./pcre_exec.c:1190
#8164 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9361a4, flags=<value optimized out>, rdepth=13) at ./pcre_exec.c:677
#8165 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9369a4,
flags=<value optimized out>, rdepth=12) at ./pcre_exec.c:1190
#8166 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9369a4, flags=<value optimized out>, rdepth=11) at ./pcre_exec.c:677
#8167 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9371a4,
flags=<value optimized out>, rdepth=10) at ./pcre_exec.c:1190
#8168 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9371a4, flags=<value optimized out>, rdepth=9) at ./pcre_exec.c:677
#8169 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9379a4,
flags=<value optimized out>, rdepth=8) at ./pcre_exec.c:1190
#8170 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
eptrb=0xbf9379a4, flags=<value optimized out>, rdepth=7) at ./pcre_exec.c:677
#8171 0xb7e2b1d6 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
ims=0, eptrb=0xbf937da4, flags=<value optimized out>, rdepth=6) at ./pcre_exec.c:1063
#8172 0xb7e2b1d6 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
ims=0, eptrb=0xbf9381a4, flags=<value optimized out>, rdepth=5) at ./pcre_exec.c:1063
#8173 0xb7e2b1d6 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
ims=0, eptrb=0xbf9385a4, flags=<value optimized out>, rdepth=4) at ./pcre_exec.c:1063
#8174 0xb7e2e004 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
ims=0, eptrb=0xbf9395a4, flags=<value optimized out>, rdepth=3) at ./pcre_exec.c:629
#8175 0xb7e2f269 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
ims=4, eptrb=0xbf938da4, flags=<value optimized out>, rdepth=2) at ./pcre_exec.c:2932
---Type <return> to continue, or q <return> to quit---
#8176 0xb7e2e004 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
ims=0, eptrb=0xbf9395a4, flags=<value optimized out>, rdepth=1) at ./pcre_exec.c:629
#8177 0xb7e2e004 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
ims=0, eptrb=0xbf9395a4, flags=<value optimized out>, rdepth=0) at ./pcre_exec.c:629
#8178 0xb7e31af3 in pcre_exec (argument_re=0x8652bf8, extra_data=0xbf9397e4,
subject=0xb72cd79c "<html>\n<head><?php // -*- php -*-\n/* Output sitemap info for directory at $path. Value is site-absolute and\n must start with a slash, so supply \"/\" to output sitemap for whole\n site. */\nfunction /"..., length=4106, start_offset=0,
options=0, offsets=0xb72cb9d8, offsetcount=12) at ./pcre_exec.c:3851
#8179 0x0809be14 in php_pcre_match_impl (pce=0x8652ee8,
subject=0xb72cd79c "<html>\n<head><?php // -*- php -*-\n/* Output sitemap info for directory at $path. Value is site-absolute and\n must start with a slash, so supply \"/\" to output sitemap for whole\n site. */\nfunction /"..., subject_len=4106,
return_value=0xb72cb8fc, subpats=0xb72cb8e4, global=0, use_flags=0, flags=0, start_offset=0)
at /home/richard/deb/php-5.2.0/ext/pcre/php_pcre.c:604
#8180 0x0809c94a in php_do_pcre_match (ht=3, return_value=0xb72cb8fc, return_value_ptr=0x6, this_ptr=0x0, return_value_used=0, global=0)
at /home/richard/deb/php-5.2.0/ext/pcre/php_pcre.c:462
#8181 0x082cf83f in zend_do_fcall_common_helper_SPEC (execute_data=0xbf9399ec) at /home/richard/deb/php-5.2.0/Zend/zend_vm_execute.h:200
#8182 0x082bf238 in execute (op_array=0xb72cb104) at /home/richard/deb/php-5.2.0/Zend/zend_vm_execute.h:92
#8183 0x082a040c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/richard/deb/php-5.2.0/Zend/zend.c:1097
#8184 0x0825b6e2 in php_execute_script (primary_file=0xbf93be20) at /home/richard/deb/php-5.2.0/main/main.c:1758
#8185 0x0832f5ae in main (argc=2, argv=0xbf93bef4) at /home/richard/deb/php-5.2.0/sapi/cli/php_cli.c:1108
[php-5.2.0-8-segfault.php (application/x-httpd-php, attachment)]
[pcre-segfault.c (text/x-csrc, attachment)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>:
Bug#405067; Package php5.
(full text, mbox, link).
Acknowledgement sent to Richard Atterer <atterer@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>.
(full text, mbox, link).
Message #10 received at 405067@bugs.debian.org (full text, mbox, reply):
On Sat, Dec 30, 2006 at 10:23:06PM +0100, Richard Atterer wrote:
> One more thing: I also tried to trim down the example further by reducing
> the length of the subject string. This gives weird results:
The following has occurred to me: The program starts crashing when the
region matched by the regex (begins with the opening <?php) is about 4000
bytes long. At this point, the stack contains some 8100 stack frames, half
of them on ./pcre_exec.c:1190, the other half on ./pcre_exec.c:677.
Thus, it is possible that the special input causes one recursive step
(i.e., one call through ./pcre_exec.c:677) for each character that is
consumed.
Cheers,
Richard
--
__ _
|_) /| Richard Atterer
| \/¯| http://geht.net.gibts.bei.atterer.net
¯ '` ¯
Information forwarded to debian-bugs-dist@lists.debian.org, Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>:
Bug#405067; Package php5.
(full text, mbox, link).
Acknowledgement sent to sean finney <seanius@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>.
(full text, mbox, link).
Message #15 received at 405067@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
hi richard,
thanks for the *very* thorough report! just so you don't think you're
being completely ignored, both ondrej and i are on vacation right now so
you probably won't see much from us for another week (or two). any more
information you can find is greatly appreciated.
sean
On Sat, 2006-12-30 at 22:23 +0100, Richard Atterer wrote:
> Package: php5
> Version: 5.2.0-8
> Severity: important
> Tags: security
>
> Hello,
>
> while developing my PHP application, I stumbled across PCRE usage which
> crashes the PHP binary. After some trial and error, I was able to reduce
> the problem to the attached piece of PHP code. I was able to reproduce the
> segfault on 3 different machines running Debian, under php 5.2.0-8
> (testing, 2 machines) and 4.3.10-18 (stable).
>
> I also compiled versions of libpcre3 and php5-cli with debugging
> information to get a stack trace. The topmost frames of the stack backtrace
> follow at the end of this message. Inside libpcre3, the code recurses
> through pcre_exec.c lines 677 and 1190 until the stack overflows.
>
> Next, I tried to find out whether the crash is reproducible with a C
> program. But while AFAICT the attached C program does the same as the code
> in php-5.2.0/ext/pcre/php_pcre.c, no segfault happens. So maybe PHP
> corrupts memory between compiling and executing the regex? I don't know!
> :-/ Running "valgrind php5 php-5.2.0-8-segfault.php" doesn't output
> anything which looks like a PCRE-related bug.
>
> One more thing: I also tried to trim down the example further by reducing
> the length of the subject string. This gives weird results: When some parts
> of the input are removed, the crash becomes "unreliable" in that executing
> "php5 php-5.2.0-8-segfault.php" will crash sometimes and sometimes it will
> not.
>
> I've "anonymized" my code by replacing alphabetic characters with "x",
> that's why it looks so weird. :)
>
> I'm tagging this "security" as this MAY potentially be a nasty bug which
> might allow more than just segfaults. If you disagree, feel free to remove
> the tag.
>
> Cheers,
>
> Richard
>
> --
> __ _
> |_) /| Richard Atterer
> | \/¯| http://geht.net.gibts.bei.atterer.net
> ¯ '` ¯
>
> #8146 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9319a4, flags=<value optimized out>, rdepth=31) at ./pcre_exec.c:677
> #8147 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9321a4,
> flags=<value optimized out>, rdepth=30) at ./pcre_exec.c:1190
> #8148 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9321a4, flags=<value optimized out>, rdepth=29) at ./pcre_exec.c:677
> #8149 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9329a4,
> flags=<value optimized out>, rdepth=28) at ./pcre_exec.c:1190
> #8150 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9329a4, flags=<value optimized out>, rdepth=27) at ./pcre_exec.c:677
> #8151 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9331a4,
> flags=<value optimized out>, rdepth=26) at ./pcre_exec.c:1190
> #8152 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9331a4, flags=<value optimized out>, rdepth=25) at ./pcre_exec.c:677
> #8153 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9339a4,
> ---Type <return> to continue, or q <return> to quit---
> flags=<value optimized out>, rdepth=24) at ./pcre_exec.c:1190
> #8154 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9339a4, flags=<value optimized out>, rdepth=23) at ./pcre_exec.c:677
> #8155 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9341a4,
> flags=<value optimized out>, rdepth=22) at ./pcre_exec.c:1190
> #8156 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9341a4, flags=<value optimized out>, rdepth=21) at ./pcre_exec.c:677
> #8157 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9349a4,
> flags=<value optimized out>, rdepth=20) at ./pcre_exec.c:1190
> #8158 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9349a4, flags=<value optimized out>, rdepth=19) at ./pcre_exec.c:677
> #8159 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9351a4,
> flags=<value optimized out>, rdepth=18) at ./pcre_exec.c:1190
> #8160 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9351a4, flags=<value optimized out>, rdepth=17) at ./pcre_exec.c:677
> #8161 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9359a4,
> flags=<value optimized out>, rdepth=16) at ./pcre_exec.c:1190
> #8162 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9359a4, flags=<value optimized out>, rdepth=15) at ./pcre_exec.c:677
> #8163 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9361a4,
> flags=<value optimized out>, rdepth=14) at ./pcre_exec.c:1190
> #8164 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9361a4, flags=<value optimized out>, rdepth=13) at ./pcre_exec.c:677
> #8165 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9369a4,
> flags=<value optimized out>, rdepth=12) at ./pcre_exec.c:1190
> #8166 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9369a4, flags=<value optimized out>, rdepth=11) at ./pcre_exec.c:677
> #8167 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9371a4,
> flags=<value optimized out>, rdepth=10) at ./pcre_exec.c:1190
> #8168 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9371a4, flags=<value optimized out>, rdepth=9) at ./pcre_exec.c:677
> #8169 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ";\n", ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9379a4,
> flags=<value optimized out>, rdepth=8) at ./pcre_exec.c:1190
> #8170 0xb7e29c04 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=6, md=0xbf939658, ims=0,
> eptrb=0xbf9379a4, flags=<value optimized out>, rdepth=7) at ./pcre_exec.c:677
> #8171 0xb7e2b1d6 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
> ims=0, eptrb=0xbf937da4, flags=<value optimized out>, rdepth=6) at ./pcre_exec.c:1063
> #8172 0xb7e2b1d6 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
> ims=0, eptrb=0xbf9381a4, flags=<value optimized out>, rdepth=5) at ./pcre_exec.c:1063
> #8173 0xb7e2b1d6 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
> ims=0, eptrb=0xbf9385a4, flags=<value optimized out>, rdepth=4) at ./pcre_exec.c:1063
> #8174 0xb7e2e004 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
> ims=0, eptrb=0xbf9395a4, flags=<value optimized out>, rdepth=3) at ./pcre_exec.c:629
> #8175 0xb7e2f269 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
> ims=4, eptrb=0xbf938da4, flags=<value optimized out>, rdepth=2) at ./pcre_exec.c:2932
> ---Type <return> to continue, or q <return> to quit---
> #8176 0xb7e2e004 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
> ims=0, eptrb=0xbf9395a4, flags=<value optimized out>, rdepth=1) at ./pcre_exec.c:629
> #8177 0xb7e2e004 in match (eptr=<value optimized out>, ecode=<value optimized out>, offset_top=<value optimized out>, md=0xbf939658,
> ims=0, eptrb=0xbf9395a4, flags=<value optimized out>, rdepth=0) at ./pcre_exec.c:629
> #8178 0xb7e31af3 in pcre_exec (argument_re=0x8652bf8, extra_data=0xbf9397e4,
> subject=0xb72cd79c "<html>\n<head><?php // -*- php -*-\n/* Output sitemap info for directory at $path. Value is site-absolute and\n must start with a slash, so supply \"/\" to output sitemap for whole\n site. */\nfunction /"..., length=4106, start_offset=0,
> options=0, offsets=0xb72cb9d8, offsetcount=12) at ./pcre_exec.c:3851
> #8179 0x0809be14 in php_pcre_match_impl (pce=0x8652ee8,
> subject=0xb72cd79c "<html>\n<head><?php // -*- php -*-\n/* Output sitemap info for directory at $path. Value is site-absolute and\n must start with a slash, so supply \"/\" to output sitemap for whole\n site. */\nfunction /"..., subject_len=4106,
> return_value=0xb72cb8fc, subpats=0xb72cb8e4, global=0, use_flags=0, flags=0, start_offset=0)
> at /home/richard/deb/php-5.2.0/ext/pcre/php_pcre.c:604
> #8180 0x0809c94a in php_do_pcre_match (ht=3, return_value=0xb72cb8fc, return_value_ptr=0x6, this_ptr=0x0, return_value_used=0, global=0)
> at /home/richard/deb/php-5.2.0/ext/pcre/php_pcre.c:462
> #8181 0x082cf83f in zend_do_fcall_common_helper_SPEC (execute_data=0xbf9399ec) at /home/richard/deb/php-5.2.0/Zend/zend_vm_execute.h:200
> #8182 0x082bf238 in execute (op_array=0xb72cb104) at /home/richard/deb/php-5.2.0/Zend/zend_vm_execute.h:92
> #8183 0x082a040c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/richard/deb/php-5.2.0/Zend/zend.c:1097
> #8184 0x0825b6e2 in php_execute_script (primary_file=0xbf93be20) at /home/richard/deb/php-5.2.0/main/main.c:1758
> #8185 0x0832f5ae in main (argc=2, argv=0xbf93bef4) at /home/richard/deb/php-5.2.0/sapi/cli/php_cli.c:1108
>
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>:
Bug#405067; Package php5.
(full text, mbox, link).
Acknowledgement sent to Cajus Pollmeier <cajus@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>.
(full text, mbox, link).
Message #20 received at 405067@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Anything new here? Anyone tried with php 5.2.1? So I'd report it to the php
team - if not already done.
The bug can be reproduced here in cli and pure apache mode. It happens when
the string to be matched is larger than 4089 bytes and a match happens.
Everything below just works fine.
Cheers,
Cajus
[test2.php (application/x-php, attachment)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>:
Bug#405067; Package php5.
(full text, mbox, link).
Acknowledgement sent to sean finney <seanius@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>.
(full text, mbox, link).
Message #25 received at 405067@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
tags 405067 confirmed wontfix upstream
forwarded 405067 http://bugs.php.net/bug.php?id=35159
thanks
hi cajus,
On Fri, 2007-03-30 at 09:47 +0200, Cajus Pollmeier wrote:
> Anything new here? Anyone tried with php 5.2.1? So I'd report it to the php
> team - if not already done.
>
> The bug can be reproduced here in cli and pure apache mode. It happens when
> the string to be matched is larger than 4089 bytes and a match happens.
> Everything below just works fine.
sorry for the delay in reponse, pretty much all of my php time has been
spent dealing with the rash of security issues lately.
anyway, regarding this issue: i've seen it mentioned upstream that php
does not handle deep recursion very well, and is prone to crash horribly
if the stack gets too big, because they keep important data such as the
zend mm on the stack. so, "it's not a bug, it's a feature" :).
references:
http://bugs.php.net/bug.php?id=35159
and others (just do a search for "recursive").
sean
[signature.asc (application/pgp-signature, inline)]
Tags added: confirmed, wontfix, upstream
Request was from sean finney <seanius@debian.org>
to control@bugs.debian.org.
(Thu, 10 May 2007 15:18:09 GMT) (full text, mbox, link).
Forcibly Merged 405067 411982.
Request was from sean finney <seanius@debian.org>
to control@bugs.debian.org.
(Sun, 25 Nov 2007 21:51:08 GMT) (full text, mbox, link).
Forcibly Merged 405067 411982 487283.
Request was from Raphael Geissert <atomo64@gmail.com>
to control@bugs.debian.org.
(Fri, 20 Jun 2008 21:21:11 GMT) (full text, mbox, link).
Disconnected #411982 from all other report(s).
Request was from Raphael Geissert <atomo64@gmail.com>
to control@bugs.debian.org.
(Tue, 26 Aug 2008 19:12:05 GMT) (full text, mbox, link).
Forcibly Merged 405067 487283 496795.
Request was from Raphael Geissert <atomo64@gmail.com>
to control@bugs.debian.org.
(Wed, 27 Aug 2008 23:57:02 GMT) (full text, mbox, link).
Tags added: fixed-upstream
Request was from bts-link-upstream@lists.alioth.debian.org
to control@bugs.debian.org.
(Mon, 20 Jul 2009 20:15:04 GMT) (full text, mbox, link).
Tags added: fixed-upstream
Request was from bts-link-upstream@lists.alioth.debian.org
to control@bugs.debian.org.
(Mon, 20 Jul 2009 20:15:14 GMT) (full text, mbox, link).
Tags added: fixed-upstream
Request was from bts-link-upstream@lists.alioth.debian.org
to control@bugs.debian.org.
(Mon, 20 Jul 2009 20:15:16 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>:
Bug#405067; Package php5.
(Sat, 17 Oct 2009 20:48:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Amr Mostafa <amr.mostafa@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>.
(Sat, 17 Oct 2009 20:48:06 GMT) (full text, mbox, link).
Message #48 received at 405067@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Increasing the allowed stack size (ulimit -s) fixed this for me. It was
suggested by "jani at php dot net" in: http://bugs.php.net/bug.php?id=48153
--
Amr Mostafa
PHP Team Leader, Egypt Development Center
amr.mostafa@egyptdc.com http://egyptdc.com
+(2012)1700502 +(202)24052355/6
[Message part 2 (text/html, inline)]
Reply sent
to Ondřej Surý <ondrej@sury.org>:
You have taken responsibility.
(Wed, 27 Apr 2011 08:33:04 GMT) (full text, mbox, link).
Notification sent
to Richard Atterer <atterer@debian.org>:
Bug acknowledged by developer.
(Wed, 27 Apr 2011 08:33:04 GMT) (full text, mbox, link).
Message #53 received at 405067-done@bugs.debian.org (full text, mbox, reply):
Version: 5.3.3-7
Hi,
since lenny is oldstable it will not get any updates now (except
security)[1], I am closing all segfault bugs filled against php5 in
lenny. (This is kind of saying that we don't care much about php5 in
lenny anymore).
If you believe the bug is still there, please provide evidence[2] and
a (preferably complete) test case with up-to-date squeeze (and/or
testing or unstable) version of php5 and reopen the bug.
O.
1. http://wiki.debian.org/PHP#Notes_on_PHP_and_security
2. Install php5-dbg and provide backtrace:
http://bugs.php.net/bugs-generating-backtrace.php
--
Ondřej Surý <ondrej@sury.org>
Reply sent
to Ondřej Surý <ondrej@sury.org>:
You have taken responsibility.
(Wed, 27 Apr 2011 08:33:05 GMT) (full text, mbox, link).
Notification sent
to Frederik Reiß <frederik.reiss@gmx.de>:
Bug acknowledged by developer.
(Wed, 27 Apr 2011 08:33:05 GMT) (full text, mbox, link).
Reply sent
to Ondřej Surý <ondrej@sury.org>:
You have taken responsibility.
(Wed, 27 Apr 2011 08:33:08 GMT) (full text, mbox, link).
Notification sent
to Gergely Nagy <algernon@bonehunter.rulez.org>:
Bug acknowledged by developer.
(Wed, 27 Apr 2011 08:33:08 GMT) (full text, mbox, link).
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Thu, 26 May 2011 07:38:37 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Sun Jul 2 01:12:12 2023;
Machine Name:
bembo
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.