Bug 473254 - PHP segfault in ld-2.9.so[110000+20000]
Summary: PHP segfault in ld-2.9.so[110000+20000]
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 10
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 484749
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-27 12:09 UTC by Igor A Tarasov
Modified: 2009-03-10 21:00 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-01-19 16:41:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
paxtest results under vanilla 2.6.28 kernel (1.70 KB, text/plain)
2009-01-17 02:36 UTC, Edward Sheldrake
no flags Details
paxtest results under rawhide 2.6.29-0.40.rc1.git6 (1.72 KB, text/plain)
2009-01-17 02:40 UTC, Edward Sheldrake
no flags Details

Description Igor A Tarasov 2008-11-27 12:09:41 UTC
Description of problem:

In Fedora-10 and in Fedora-9 with last updates.

Sometimes, php scripts crash with Segmentation Fault.
Message from dmesg:
"php[13238] general protection ip:1201eb sp:bfa68910 error:0 in ld-2.9.so[110000+20000]"

Version-Release number of selected component (if applicable):
glibc-2.9-2.i686

How reproducible:
Sometimes, not always, from run to run of the same php script.

Comment 1 Edward Sheldrake 2008-12-04 21:39:51 UTC
I'm also seeing this bug, however the general protection fault occasionally stops other programs from starting e.g. gedit, firefox but not "/bin/true".

php[10398] general protection ip:1201eb sp:bf890860 error:0 in ld-2.9.so[110000+20000]

I ran some loops with shell scripts, gedit opening the same file or "php -version". gedit has about 1 in 500 chance of segfaulting, "php -version" crashed 7 times out of 1500.

I think the random crashes started with kernel 2.6.27 on Fedora 9 and continues with Fedora 10:
kernel-2.6.27.5-41.fc9.i686
kernel-2.6.27.5-117.fc10.i686

I compiled vanilla kernel 2.6.27.7 myself, "php -version" executed successfully 4500 times, and gedit started without any crashes a similar number of times.

So the component needs to be changed to kernel.

Comment 2 Edward Sheldrake 2008-12-07 10:57:52 UTC
Same issue with kernel-2.6.27.7-134.fc10.i686.

With this kernel I did:
# echo 0 > /proc/sys/kernel/exec-shield

and then there were no further general protection faults.

I have a 2.0 GHz Pentium 4 Northwood CPU, "Using x86 segment limits to approximate NX protection".

Comment 3 Erik Terwan 2009-01-10 16:43:13 UTC
Still experiencing this problem with kernel 2.6.27.9-159.fc10.i686. Solution of previous comment (disabling the exec-shield protection) prevents the segfault, but is not a real solution.

Errors (in /var/log/messages):
kernel: php[8070] general protection ip:8f61eb sp:bf87c2e0 error:0 in ld-2.9.so[8e6000+20000]
kernel: php[8201] general protection ip:8f61eb sp:bfa1d780 error:0 in ld-2.9.so[8e6000+20000]
kernel: php[8248] general protection ip:8f61eb sp:bfa1f2d0 error:0 in ld-2.9.so[8e6000+20000]

Software versions:
php-5.2.6-5.i386
kernel-2.6.27.9-159.fc10.i686
glibc-2.9-3.i686

Comment 4 Edward Sheldrake 2009-01-15 23:37:17 UTC
Problem persists with kernel-2.6.28-3.fc10.i686 from koji.

With 2 in /proc/sys/kernel/print-fatal-signals , there were a lot of "GPF fixup" lines in dmesg, but presumably this occasionally doesn't happen when it should.

I looked at the exec-shield patch, and I think this change:
http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-10/linux-2.6-execshield.patch?r1=1.96&r2=1.97

which may have originated from:
https://bugzilla.redhat.com/attachment.cgi?id=298996

is the problem. The bitmask seems wrong, it misses some bits from the limit in the middle, and it's applied to the wrong member? The test should be:

if (desc1->a != desc2->a ||
(desc1->b & 0xff0f00ff) != (desc2->b & 0xff0f00ff))

(struct desc_struct is in arch/x86/include/asm/desc_defs.h)

I briefly tested a 2.6.28 vanilla kernel with just my fixed version of the exec-shield patch applied, there were no random GPFs, the exploits from libsafe-2.0-16 were stopped by exec-shield with GPFs, however this kernel wasn't loading shared libraries at randomized locations for some reason.

Comment 5 Kyle McMartin 2009-01-17 00:40:12 UTC
Thanks for your detailed analysis! I (think) I've fixed it (using desc->limit, desc->base instead of the mask, to make what it's doing obvious.) but I can't seem to reproduce it with while true; do php -version; done on a Pentium 3... strange.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1059889 is the scratch build, although against rawhide, not 2.6.28.

regards, Kyle

Comment 6 Edward Sheldrake 2009-01-17 02:34:39 UTC
With the rawhide scratch kernel, the only GPFs were from the libsafe and paxtest programs, but like my 2.6.28+exec-shield, the addresses for shared libraries shown by ldd were not randomized. It doesn't seem like a fair test, or is this feature no longer available? I will attach the paxtest results.

Comment 7 Edward Sheldrake 2009-01-17 02:36:53 UTC
Created attachment 329267 [details]
paxtest results under vanilla 2.6.28 kernel

vanilla 2.6.28, exec-shield not present, addresses are randomized

Comment 8 Edward Sheldrake 2009-01-17 02:40:17 UTC
Created attachment 329268 [details]
paxtest results under rawhide 2.6.29-0.40.rc1.git6

specially built kernel with fixed? exec-shield, but some randomization no longer present

Comment 9 Kyle McMartin 2009-01-17 05:51:32 UTC
I think I've spotted where the randomization problem is, I'll do a build tomorrow and post it here.

cheers, Kyle (still wondering how I ended up maintaining this patch. ;-)

Comment 10 Kyle McMartin 2009-01-19 05:54:59 UTC
Hi, I've fixed the ET_EXEC/ET_DYN problem I think.

Care to test the packages in this scratch build (This time based on F-10...)

http://koji.fedoraproject.org/koji/taskinfo?taskID=1065193

cheers, Kyle

Comment 11 Edward Sheldrake 2009-01-19 16:02:23 UTC
Everything is OK with kernel 2.6.28.1-10.nx3.fc10.i686, exec-shield is working correctly and the randomization is present, thanks.

Comment 12 Kyle McMartin 2009-01-19 16:41:36 UTC
No problemo, thanks for filing your detailed bug report which let us track down these issues. :)


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