This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12189] __stack_chk_fail should not attempt a backtrace (CVE-2010-3192)


https://sourceware.org/bugzilla/show_bug.cgi?id=12189

--- Comment #23 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Florian Weimer <fw@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a289ea09ea843ced6e5277c2f2e63c357bc7f9a3

commit a289ea09ea843ced6e5277c2f2e63c357bc7f9a3
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Aug 19 15:41:29 2019 +0200

    Do not print backtraces on fatal glibc errors

    If the process is in a bad state, we used to print backtraces in
    many cases.  This is problematic because doing so could involve
    a lot of work, like loading libgcc_s using the dynamic linker,
    and this could itself be targeted by exploit writers.  For example,
    if the crashing process was forked from a long-lived process, the
    addresses in the error message could be used to bypass ASLR.

    Commit ed421fca42fd9b4cab7c66e77894b8dd7ca57ed0 ("Avoid backtrace from
    __stack_chk_fail [BZ #12189]"), backtraces where no longer printed
    because backtrace_and_maps was always called with do_abort == 1.

    Rather than fixing this logic error, this change removes the backtrace
    functionality from the sources.  With the prevalence of external crash
    handlers, it does not appear to be particularly useful.  The crash
    handler may also destroy useful information for debugging.

    Reviewed-by: Carlos O'Donell <carlos@redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]