[PATCH] Avoid deadlock in malloc on backtrace

[Siddhesh Poyarekar]

On Tue, Feb 24, 2015 at 11:31:02AM +0100, Florian Weimer wrote:
> Hasn't GCC a backtrace library which does not use malloc?

Yes, backtrace uses it (unwinder support in libgcc_s).  It doesn't use
malloc directly, but dynamically loading the library requires malloc.

> From a security point of view, this is wrong.  glibc should not try to
> attempt to do even more work if a heap corruption is detected.  The

In the heap corruption workflow, the only extra work it does is to
mark the arena as corrupt, which is to set a single flag in a memory
location that is never used by the chunk allocator.  Everything else
works exactly the way it has been.

> proper fix would be to use a coredump handler to print the backtrace,
> completely outside the process.  This also has the advantage that the
> backtrace can use separate/compressed debugging information.

Agreed, but that would be beyond the scope of glibc.  The other
alternative would be to remove the option completely, but I don't know
if that would be a popular choice.  the backtrace and map dump is
informative, but I don't know how many developers actually understand
it.  Even if we keep it as a non-default option, we'll have to fix the
deadlock and the stack overflow.

> Maybe from a functionality point of view, this is the right thing to do.
> 
> The test case is invalid for multiple reasons: the compiler can detect
> that the pointer arithmetic before the allocated buffer is invalid.
> There is a use-after-free.  Maybe it's possible to fix this with
> -ffreestanding; I don't know if the glibc headers obey that, though.

This is intentional to induce a memory corruption that results in the
deadlock.

Siddhesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150224/033cf38b/attachment.sig>