Bug#233996: libc6: non-debug binaries do odd things to the stack

[Daniel Jacobowitz <dan@debian.org>]

reassign 233996 libsafe
thanks

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
     debugging purposes.

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer