Bug#233996: libc6: non-debug binaries do odd things to the stack
reassign 233996 libsafe
On Sat, Feb 21, 2004 at 02:42:46AM -0500, Ben Winslow wrote:
> One other place I encountered the problem was while trying to walk the
> stack in an LD_PRELOADed library that wrapped around gettimeofday(). I
> used __builtin_frame_address (a gcc internal) to walk backwards through
> the stack (the function is supposed to return 0 when the top of the stack
> is reached.) The results end with some characters of the program name
> (which is stored after the stack) with a non-debug libc.
> The libsafe package is affected by this bug, because it relies on a
> valid stack in order to determine whether or not a variable is stack or
> heap, and the size of that variable should it reside on the stack.
> Since libsafe always fails to determine that a variable is on the stack
> (and presumes it's on the heap, instead), libsafe is rendered completely
> ineffective, which is why I marked this bug with the 'security' tag.
That is libsafe's fault. I recommend that you read the GCC
documentation describing __builtin_frame_address. It's not clear on
this point; I believe GCC 3.4's manual will be clearer. In particular:
This function should only be used with a nonzero argument for
because it does not work. There is no reliable way to unwind the stack
without .eh_frame or .debug_frame information; libc6 optimized
libraries are built with -O2 -fomit-frame-pointer, that's all. On
other architectures this may be true of all code. AMD64 for instance.
MontaVista Software Debian GNU/Linux Developer