Red Hat Bugzilla – Bug 57760
gcc-generated code accesses stack below sp
Last modified: 2007-04-18 12:38:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2)
Description of problem:
In certain leaf functions, the code generated by gcc does not allocate a
new stack frame, i.e. it does not subtract from %esp in the function
prelude, yet the remainder of the code accesses stack-allocated local
variables (at negative offsets w.r.t %ebp). This results in accesses to
stack locations below the stack pointer %esp. These locations can be wiped
at any time by a signal handler, causing the program to crash. Also, this
can invalidate the stack growing heuristic in the kernel, causing the
program to be killed on a segmentation violation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile the attached md5.c file with "gcc -O -S"
2. Look at md5.s, function MD5Transform, and notice the lack of
a "subl $NNN, %esp" instruction in the prelude, and the accesses
" movl %eax, -16(%ebp)" later in the code.
This is the same bug as #55568, but with a much smaller code fragment to
Created attachment 41168 [details]
excerpt from Colin Plumb's MD5 implementation demonstrating wrong generated code
We also ran into this bug when compiling the SHA1 code in the
Network Security Services (NSS) libraries on Red Hat Linux 7.2.
The code generated by gcc 2.96-81 on Red Hat Linux 7.1 is good.
I will attach an excerpt of the SHA1 code in NSS.
Created attachment 41207 [details]
excerpt from NSS 3.3.2's SHA1 implementation demonstrating wrong generated code
Created attachment 41208 [details]
diffs between the assembler files generated by 'gcc -S -O2 -fPIC sha1.c' on 7.1 and 7.2
Should be fixed in gcc-2.96-103, currently at:
This is good news. Thanks.
We will need to wait for an official Red Hat Linux 7.2 update
that includes this fix though. Do you know when that will be
I verified that gcc 2.96-103 generates the same code from my sha1.c
test case as gcc 2.96-81.
So this is not fixed?
This is fixed. gcc 2.96-81 and gcc 2.96-103 generate the
correct code. It's 2.96-98 (the gcc in Red Hat Linux 7.2)
that has the bug.
OK, then the bug is fixed.