php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66059 Segmentation fault with backslashes in output
Submitted: 2013-11-08 09:31 UTC Modified: 2013-11-08 20:51 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:3 (75.0%)
Same OS:2 (50.0%)
From: chris dot riesen at gmail dot com Assigned:
Status: Not a bug Package: PCRE related
PHP Version: Irrelevant OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: chris dot riesen at gmail dot com
New email:
PHP Version: OS:

 

 [2013-11-08 09:31 UTC] chris dot riesen at gmail dot com
Description:
------------
On executing some code within the symfony framework this bug has shown up. It appears to be a problem with a large number of backslashes. This is a valid use case as it can happen with messages that are escaped (my example was escaped json, which led me to this bug).

This has been tested and is reproducible on these environments:
- suse enterprise linux x64, php 5.3.17, full physical machine
- ubuntu 13.10 x64, php 5.5.3, virtual box

From what I see it's the preg_replace_callback that makes it go haywire:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Console/Formatter/OutputFormatter.php#L150

To simply reproduce, install a blank symfony project with composer, make a script with the autoloader in it then use the code below.

Test script:
---------------
$formatter = new Symfony\Component\Console\Formatter\OutputFormatter(true);
$formatter->format('<error>Error</error>' . str_repeat("\\", 14000));

Expected result:
----------------
Anything but a segfault.

Actual result:
--------------
Core was generated by `php test.php'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f40db9acd57 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
(gdb) bt
#0  0x00007f40db9acd57 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#1  0x00007f40db9ae02d in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
Same line, just different memory location for a while until:
#10892 0x00007f40db9afae5 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#10893 0x00007f40db9ba89b in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#10894 0x00007f40db9bd93c in pcre_exec () from /lib/x86_64-linux-gnu/libpcre.so.3
#10895 0x00000000004a7b95 in php_pcre_replace_impl ()
#10896 0x00000000004a8a79 in ?? ()
#10897 0x00000000004a9078 in ?? ()
#10898 0x000000000079b9aa in ?? ()
#10899 0x0000000000715458 in execute_ex ()
#10900 0x00000000006ed290 in zend_execute_scripts ()
#10901 0x000000000068d5d5 in php_execute_script ()
#10902 0x000000000079d75e in ?? ()
#10903 0x0000000000461bc0 in main ()

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-11-08 10:03 UTC] chris dot riesen at gmail dot com
-Package: Reproducible crash +Package: PCRE related
 [2013-11-08 10:03 UTC] chris dot riesen at gmail dot com
More precise it's a PCRE issue.
 [2013-11-08 10:05 UTC] webmaster at tubo-world dot de
Can be easily reproduced with the following plain PHP code:

echo preg_replace_callback(
    '#(\\\\?)<(/?)([a-z][a-z0-9_=;-]*)?>((?: [^<\\\\]+ | (?!<(?:/?[a-z]|/>)). | .(?<=\\\\<) )*)#isx',
    function($match) { return 'a'; },
    '<error>Error</error>' . str_repeat("\\", 14000)
);
 [2013-11-08 12:12 UTC] chris dot riesen at gmail dot com
Crashes on all php versions present in this sandbox:
http://sandbox.onlinephpfunctions.com/code/028d78a78c6bb258a2a86b185ad5f9e35aac5230
 [2013-11-08 20:51 UTC] bwoebi@php.net
-Status: Open +Status: Not a bug
 [2013-11-08 20:51 UTC] bwoebi@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

It's known PCRE problem, not a PHP issue. Check out other PCRE related reports.
By increasing stack size, it might work again.
 [2013-11-09 03:18 UTC] webmaster at tubo-world dot de
Similar to https://bugs.php.net/bug.php?id=45735 and https://bugs.php.net/bug.php?id=40909

You say it's a known PCRE problem and not PHPs problem. But I cannot find an open bug report on PCRE. Only closed ones like http://bugs.exim.org/show_bug.cgi?id=577 or some doc like http://manpages.courier-mta.org/htmlman3/pcrestack.3.html. So apparently PCRE has no intention to at least fail gracefully as well.

To sum up, a 10 year old problem that people run into again and again is not even considered for fixing by any party. Btw, this also means that one can potentially crash/exploit many PHP apps who use regexes to validate or process user entered data by just submitting a long enough string.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 21:01:36 2024 UTC