This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12189] __stack_chk_fail should not attempt a backtrace
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 30 Aug 2013 19:12:50 +0000
- Subject: [Bug libc/12189] __stack_chk_fail should not attempt a backtrace
- Auto-submitted: auto-generated
- References: <bug-12189-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=12189
--- Comment #8 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #7)
> I would like an even more extreme fix, removing all possibility of output
> from __*_chk_fail and having them immediately abort() or similar (but see
> the caveats that follow). Once the program state is compromised, any further
> execution could turn a DoS vulnerability into a code-execution one. Even
> things like the vdso syscall pointer at %gs:whatever should not be trusted
> at this point, because you already have evidence that the program state is
> compromised; a stack-based buffer overflow on a non-main thread could easily
> reach into the TCB.
>
> In musl, we have an inline function called a_crash() for things like this;
> it's defined as __asm__ __volatile__ ("hlt"); on x86 and intended to be
> defined analogously on other archs, although right now it's just *(volatile
> char *)0=0; on most.
We have ABRT_INSTRUCTION in glibc for all targets and we could use it in this
case. I don't disagree with your rationale behind why glibc shouldn't print a
backtrace, but it still needs a champion to post the patch on libc-alpha and
get consensus. It seems like we would likely have 2 or 3 immediate ACKs for
this patch. I'm leaving it up to Kees to push it forward.
--
You are receiving this mail because:
You are on the CC list for the bug.