[Bug libc/12225] New: Incorrect mprotect after dlopen of object requiring execstack

["jseward at acm dot org" <sourceware-bugzilla at sourceware dot org>]

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.