This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11968] longjmp fails with _FORTIFY_SOURCE=2 on x86_64
- From: "kees at outflux dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 2 Sep 2010 18:22:02 -0000
- Subject: [Bug libc/11968] longjmp fails with _FORTIFY_SOURCE=2 on x86_64
- References: <20100902181545.11968.kees@outflux.net>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- 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.