Bug 190084 - php causing nasty segfaults with current rawhide
php causing nasty segfaults with current rawhide
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Joe Orton
David Lawrence
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-27 09:28 EDT by Reuben Farrelly
Modified: 2008-05-06 20:28 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:28:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Reuben Farrelly 2006-04-27 09:28:08 EDT
Description of problem:
php appears to be causing nasty segfaults with current rawhide.  This has
started in the last few days, and I'm unsure quite why it is occuring given none
of the packages involved have been touched.

I am seeing this logged in /var/log/messages:

Apr 28 01:03:59 tornado kernel: httpd[4474]: segfault at 00007fffc4cf8b60 rip 00
002af7eb447bbd rsp 00007fffc4cf8b30 error 6
Apr 28 01:06:39 tornado kernel: httpd[4630]: segfault at 00007fffbe8db750 rip 00
002b5ff1864bbd rsp 00007fffbe8db720 error 6

Any attempt to view the site in question results in httpd closing the connection
with no data sent.

It appears to be only one specific site running mambo on the server that causes
this.  Other sites with simple php are OK.

Version-Release number of selected component (if applicable):
[current rawhide, ie php 5.1.2-5, httpd-2.2.0-6]

How reproducible:
100% every time with this one site.

Steps to Reproduce:
1. visit site
2. watch apache child processes segfault and die

Additional info:

I have also moved the contents of /etc/php.d/*.ini into another directory -
restarted httpd and noted that the problem still occurs, so my impression is
that this is not specific to any php module.  By turning off the php module the
gory code of the site is displayed rather than apache dying as it normally does.

Nothing is logged when the requests for this site come in other than 
[Fri Apr 28 01:06:40 2006] [notice] child pid 4630 exit signal Segmentation faul
t (11)
in /var/log/httpd/error-log.

It may be handy to start off by just bumping httpd and php so they are rebuilt -
and see if that helps resolve the problem.

Content of a website should obviously never be able to cause httpd to die.
Comment 1 Joe Orton 2006-04-27 09:30:13 EDT
Any LDAP use on this site?  Please get a backtrace:

# echo CoreDumpDirectory /tmp > /etc/httpd/conf.d/core.conf
# yum install php-debuginfo httpd-debuginfo
<... trigger core dump...>
# gdb /usr/sbin/httpd /tmp/core.*
...
(gdb) bt full

Comment 2 Reuben Farrelly 2006-04-27 09:32:17 EDT
No ldap:

[root@tornado modules]# rpm -q php-ldap
package php-ldap is not installed
[root@tornado modules]#

Working on the backtraces now.
Comment 3 Reuben Farrelly 2006-04-27 09:50:30 EDT
It doesn't seem to produce any core files, I'm not sure why.

However I did manage to get gdb to attach to one of the running processes which
I managed to get to die, and got this:

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47882735855872 (LWP 13799)]
0x00002b8c9527bbbd in virtual_file_ex (state=0x7fff1aec6df0,
    path=0x555557903448
"/var/www/html/www.knsolutions.com.au/configuration.php", verify_path=0,
use_realpath=1)
    at /usr/src/debug/php-5.1.2/TSRM/tsrm_virtual_cwd.c:373
373     {
(gdb) bt full
#0  0x00002b8c9527bbbd in virtual_file_ex (state=0x7fff1aec6df0,
    path=0x555557903448
"/var/www/html/www.knsolutions.com.au/configuration.php", verify_path=0,
use_realpath=1)
    at /usr/src/debug/php-5.1.2/TSRM/tsrm_virtual_cwd.c:373
        path_length = Variable "path_length" is not available.
(gdb)

Does that provide any useful info?
[It has given me a clue that maybe something in the contents of that text
configuration file is perhaps involved...]
Comment 4 Reuben Farrelly 2006-04-27 19:12:10 EDT
Ok I've resolved this one now.  It was an error in the config file.

The problem was an extra linefeed in the configure.php file:

$mosConfig_MetaKeys = 'KNSolutions, I.T support NSW, Hardware, Software,
webdesign, Hosting, Knsolutions, Solutions, Future,';
$mosConfig_MetaAuthor = '1';

Taking that extra linefeed out and the problem went away.  What is interesting
is that an end user configuring his site caused this, it was not caused by me
hand editing the script ie the end user was only writing to the file with the
permissions of httpd via the administration interface on the site.

The question remains as to how a php script error could cause php to die like
that.  That would surely be borderline in terms of security?  Certainly it
points to a weakness in terms of stability if nothing else - if a crash can be
triggered so easily.
Comment 5 Joe Orton 2006-05-17 10:12:57 EDT
Hopefully the root cause will have been fixed in 5.1.4; without more backtrace
it's hard to track this down any further.
Comment 6 Reuben Farrelly 2006-05-18 05:42:58 EDT
Joe can you push this out to rawhide or people.redhat.com for me to test please?
 Looks like the changes were made to upgrade php on 8 May but it's still not
visible in Rawhide...
Comment 7 Joe Orton 2006-05-18 09:42:53 EDT
Sorry, not sure why that's so; another one is being built right now so it should
show up tomorrow.
Comment 8 Reuben Farrelly 2006-05-18 22:09:53 EDT
The problem is still present in 5.1.4.

I can totally DoS my apache server and get the child processes to all segfault
by running a site with a slightly broken configuration.php file from mambo
(extra CR in the middle of a line).
Comment 9 Reuben Farrelly 2006-05-21 07:10:27 EDT
Does this help?  This is from running httpd -X under gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47933561780528 (LWP 12104)]
0x00002b986a90c48d in virtual_file_ex () from /etc/httpd/modules/libphp5.so
(gdb) bt full
#0  0x00002b986a90c48d in virtual_file_ex () from /etc/httpd/modules/libphp5.so
No symbol table info available.
#1  0x00002b986a9137fc in expand_filepath () from /etc/httpd/modules/libphp5.so
No symbol table info available.
#2  0x00002b986a92523e in _php_stream_fopen ()
   from /etc/httpd/modules/libphp5.so
No symbol table info available.
#3  0x00002b986a92547e in _php_stream_fopen_with_path ()
   from /etc/httpd/modules/libphp5.so
No symbol table info available.
#4  0x00002b986a9220cf in _php_stream_open_wrapper_ex ()
   from /etc/httpd/modules/libphp5.so
No symbol table info available.
#5  0x00002b986a90dc14 in php_set_error_handling ()
   from /etc/httpd/modules/libphp5.so
No symbol table info available.
#6  0x00002b986a9702f0 in execute () from /etc/httpd/modules/libphp5.so
No symbol table info available.
#7  0x00002b986a9689dc in execute () from /etc/httpd/modules/libphp5.so
No symbol table info available.
#8  0x00002b986a978442 in execute () from /etc/httpd/modules/libphp5.so
No symbol table info available.
Comment 10 Joe Orton 2006-05-22 06:19:25 EDT
Can you install the new php-debuginfo and regenerate the backtrace?

(a minimal script to reproduce the crash would be nice if possible to;
appreciate this might be difficult of course)
Comment 11 Reuben Farrelly 2006-08-14 19:51:09 EDT
Ok this is all I can seem to get, although the crash is still happening on 
demand so it's perfectly repeatable:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47568067112656 (LWP 24573)]
0x00002b4354c2489d in virtual_file_ex (state=0x7fff60660b00, 
    
path=0x5555564bed58 "/var/www/html/www.knsolutions.com.au//configuration.php", 
verify_path=0, use_realpath=1)
    at /usr/src/debug/php-5.1.4/TSRM/tsrm_virtual_cwd.c:367
367     {
(gdb) 
(gdb) bt full
#0  0x00002b4354c2489d in virtual_file_ex (state=0x7fff60660b00, 
    
path=0x5555564bed58 "/var/www/html/www.knsolutions.com.au//configuration.php", 
verify_path=0, use_realpath=1)
    at /usr/src/debug/php-5.1.4/TSRM/tsrm_virtual_cwd.c:367
        path_length = <value optimized out>
        ptr = <value optimized out>
        path_copy = <value optimized out>
        tok = Cannot access memory at address 0x7fff6065eaa8
(gdb) 

There's no script to create this, however it is easily reproduced with a 
standard install of latest stable mambo.  Just edit the configuration.php file 
and add a carriage return mid line in say, $mosConfig_MetaKeys = ' <cr> '.  
Then watch apache burn as you surf to the front page of the site..

This is with the latest php as per rawhide.

Comment 12 Joe Orton 2007-05-25 10:18:08 EDT
Is this still reproducible with current Raw Hide/5.1.6?
Comment 13 Reuben Farrelly 2007-05-26 08:53:10 EDT
I can't confirm this, sorry.  I no longer have any systems running rawhide...
Comment 14 Bug Zapper 2008-04-03 13:13:35 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 15 Bug Zapper 2008-05-06 20:28:53 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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