[Bug libc/11968] New: longjmp fails with _FORTIFY_SOURCE=2 on x86_64

[Bug libc/11968] New: longjmp fails with _FORTIFY_SOURCE=2 on x86_64

[kees at outflux dot net]

Since 2.11 and later, it seems that longjmp will fail on x86_64 when
_FORTIFY_SOURCE is enabled.

Works on x86_32, and 2.10 and earlier.

https://launchpad.net/bugs/601030

-- 
           Summary: longjmp fails with _FORTIFY_SOURCE=2 on x86_64
           Product: glibc
           Version: 2.11
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: kees at outflux dot net
                CC: glibc-bugs at sources dot redhat dot com


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11968] longjmp fails with _FORTIFY_SOURCE=2 on x86_64

[kees at outflux dot net]

------- Additional Comments From kees at outflux dot net  2010-09-02 18:22 -------
Created an attachment (id=4962)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4962&action=view)
reproducer

Here is the reproducer. This dies on alarm on Ubuntu x86_64 (eglibc 2.11 and
2.12) and Fedora x86_64 (2.12) when using more recent glibc:

$ gcc -O2 -fno-stack-protector -D_FORTIFY_SOURCE=2 -Wall minimal.c -o minimal
/tmp
$ ./minimal 
Alarm Clock

It doesn't always fail, and I tried to mitigate this by disabling ASLR.

Michael Hope noticed:

"The fault occurs as the 'pass' value given to longjmp() gets corrupted before
use by setjmp(), causing the 'setjmp() < 2' test to fail and the system to loop
forever. The only assembler level fortify/non-fortify difference is a call to
longjmp_chk instead of longjmp.

Note that shifting 'mystack' off the stack and into static memory also works
around the problem.

glibc-2.11.1/sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S is broken. It
saves the value of 'pass' in ecx for later use but ecx is trashed by a syscall.


The syscall is used to bring in the signal stack so that the fortify code can
print an error message if needed. The problem goes away with -U_FORTIFY_SOURCE
as no such syscall is used."

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11968] longjmp fails with _FORTIFY_SOURCE=2 on x86_64

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-09-08 22:52 -------
Fixed in git.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11968] longjmp fails with _FORTIFY_SOURCE=2 on x86_64

[kees at outflux dot net]

------- Additional Comments From kees at outflux dot net  2010-09-08 23:04 -------
Thanks!

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c044aa75354b48d4b7aaffe465706282192e54c2

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.