This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12225] New: Incorrect mprotect after dlopen of object requiring execstack
- From: "jseward at acm dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 17 Nov 2010 21:14:46 +0000
- Subject: [Bug libc/12225] New: Incorrect mprotect after dlopen of object requiring execstack
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=12225
Summary: Incorrect mprotect after dlopen of object requiring
execstack
Product: glibc
Version: 2.12
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper.fsp@gmail.com
ReportedBy: jseward@acm.org
Created attachment 5126
--> http://sourceware.org/bugzilla/attachment.cgi?id=5126
small test case (tar file containing try1.c and try1so.c)
When glibc dlopens an object that requires executable stack, it
honours that request by using mprotect to change the perms on the
main thread stack + probably various others from rw- to rwx
(at sysdeps/unix/sysv/linux/dl-execstack.c:57)
For the main thread stack, it quite often misses out the last
(highest addressed) page of the stack, or the last 2 pages of the
stack. You can see this by looking at /proc/../maps for the
process before and after the dlopen -- the [stack] entry is split
into two pieces by the call.
The number of pages missed by the mprotect changes from run to
run in an apparently random way (ASLR induced, perhaps) but is
always either 0, 1 or 2.
For code which tries to determine the last page in the stack by
calling pthread_attr_getstack and adding the returned stackaddr
and stacksize values, this causes different values before and
after the call.
This causes debug builds of Firefox to assert during Javascript
garbage collection (requiring stack scanning) if the Firefox
process has previously dlopened any object requiring execstack,
as some graphics drivers do. See
https://bugzilla.mozilla.org/show_bug.cgi?id=608526
If the loaded object is not marked as requiring execstack then
none of these inconsistencies happen.
Small test case attached (tar file with try1.c and try1so.c):
$ gcc -g -Wall -shared -o try1so.so try1so.c
$ gcc -g -Wall -o try1 try1.c -ldl -lpthread
$ execstack -q ./try1so.so
- ./try1so.so
$ ./try1 ## the two stack base numbers are always the same
$ execstack -s ./try1so.so
$ execstack -q ./try1so.so
X ./try1so.so
$ ./try1 ## the two stack base numbers differ by 0, 1 or 2
## pages
Confirmed on Ubuntu 10.04 (x86_64), 10.10 (x86_64) and Fedora 13
(x86_64). These last two are glibc-2.12.1.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.