gdb and binutils branch master updated. 184cd07257b5dd74a4eb9f6857fc6dd785f53492

[jkratoch@sourceware.org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  184cd07257b5dd74a4eb9f6857fc6dd785f53492 (commit)
      from  dcf893b581c440902d68a0095967acd4ae7ae8d1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=184cd07257b5dd74a4eb9f6857fc6dd785f53492

commit 184cd07257b5dd74a4eb9f6857fc6dd785f53492
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Fri Feb 21 18:39:40 2014 +0100

    Fix crash on process name "(sd-pam)" (PR 16594).
    
    info os processes -fsanitize=address error
    https://sourceware.org/bugzilla/show_bug.cgi?id=16594
    
    info os processes
    =================================================================
    ==5795== ERROR: AddressSanitizer: heap-use-after-free on address
    0x600600214974 at pc 0x757a92 bp 0x7fff95dd9f00 sp 0x7fff95dd9ef0
    READ of size 4 at 0x600600214974 thread T0
        #0 0x757a91 in get_cores_used_by_process (.../gdb/gdb+0x757a91)
    
    At least Fedora 20 has process(es):
     6678 ?        Ss     0:00 /usr/lib/systemd/systemd --user
     6680 ?        S      0:00  \_ (sd-pam)
    
    and GDB "info os processes" crashes on it as /proc/6680/stat contains:
    
    6680 ((sd-pam)) S 6678 6678 6678 0 -1 1077961024 33 0 0 0 0 0 0 0 20 0 1 0 18568 73768960 120 18446744073709551615 1 1
    0 0 0 0 0 4096 0 18446744073709551615 0 0 17 6 0 0 0 0 0 0 0 0 0 0 0 0 0
    
    and GDB fails to find the proper end of the process name "((sd-pam))".
    Therefore it reads core number off-by-one (it reads 17 instead of 6) and
    overruns the array.
    
    (1) Make the process name parsing more foolproof.
    
    (2) Do not trust the parsed number from /proc/PID/stat and verify it against
        the array size.
    
    I noticed that 'ps' gets this right, so I've peeked at its
    sources, and it just looks for the first ')' starting at
    the end.
    
    https://gitorious.org/procps/procps/source/dc072aced7250fed9b01fb05f0d672678752a63e:proc/readproc.c
    
    Look for stat2proc.
    
    Given ps does that, I believe the kernel won't ever be changed
    in a way that would break it.  So it sounds like could do strrchr
    from the end of stat just as well without worry, which is simpler.
    
    gdb/
    2014-02-21  Jan Kratochvil  <jan.kratochvil@redhat.com>
    
    	PR gdb/16594
    	* common/linux-osdata.c (linux_common_core_of_thread): Find the end of
    	process name.
    	(get_cores_used_by_process): New parameter num_cores, use it.
    	(linux_xfer_osdata_processes): Pass num_cores to it.
    	* linux-tdep.c (linux_info_proc, linux_fill_prpsinfo): Find the end of
    	process name.
    
    Message-ID: <20140217212826.GA15080@host2.jankratochvil.net>

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog             |   10 ++++++++++
 gdb/common/linux-osdata.c |   16 ++++++----------
 gdb/linux-tdep.c          |   18 +++++++++++-------
 3 files changed, 27 insertions(+), 17 deletions(-)


hooks/post-receive
-- 
gdb and binutils