Bug 11968 - longjmp fails with _FORTIFY_SOURCE=2 on x86_64
Summary: longjmp fails with _FORTIFY_SOURCE=2 on x86_64
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.11
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-02 18:15 UTC by Kees Cook
Modified: 2014-06-30 08:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-

Attachments
reproducer (978 bytes, text/plain)
2010-09-02 18:22 UTC, Kees Cook 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kees Cook 2010-09-02 18:15:45 UTC 
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
Comment 1 Kees Cook 2010-09-02 18:22:00 UTC 
Created attachment 4962 [details]
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."
Comment 2 Ulrich Drepper 2010-09-08 22:52:49 UTC 
Fixed in git.