This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/12416] Dynamic linker incorrectly reduces the stack size when making it executable


http://sourceware.org/bugzilla/show_bug.cgi?id=12416

Rodrigo Kumpera <kumpera at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #3 from Rodrigo Kumpera <kumpera at gmail dot com> 2011-01-19 19:25:21 UTC ---
I believe this is really not the case, if we look at the next mapping after the
stack is made executable, a hole is introduced:


found stack:         7fff9c51a000-7fff9c53b000 rw-p 00000000 00:00 0           
              [stack]
entry after stack: 7fff9c5ff000-7fff9c600000 r-xp 00000000 00:00 0             
            [vdso]

found stack:         7fff9c51a000-7fff9c53a000 rwxp 00000000 00:00 0           
              [stack]
entry after stack: 7fff9c53b000-7fff9c53b000 rw-p 00000000 00:00 0 

strace gives:

mprotect(0x7fff9c539000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) =
0

So mprotect is ignoring the last page and producing one unmapped page.


But how about this one:

found stack:         7fffe0ebf000-7fffe0ee0000 rw-p 00000000 00:00 0           
              [stack]
entry after stack: 7fffe0fbc000-7fffe0fbd000 r-xp 00000000 00:00 0             
            [vdso]

found stack:         7fffe0ebf000-7fffe0ede000 rwxp 00000000 00:00 0           
              [stack]
entry after stack: 7fffe0edf000-7fffe0ee0000 rw-p 00000000 00:00 0 

mprotect(0x7fffe0edd000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) =
0

Here mprotect is ignoring the top 2 pages of the stack and producing one
unmapped page.

Both of the above results where with the exact same binary, so how much of the
stack will be slashed by
glibc is hard to predict.

It's very hard to defend that the unpredictable value passed to mprotect is a
kernel bug.

-- 
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]