[Bug binutils/28423] use-after-free in objdump at disassemble_bytes objdump.c:3059

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Alan Modra <amodra@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=66468343379e535c6804a075709b5b49b09c6ed8

commit 66468343379e535c6804a075709b5b49b09c6ed8
Author: Alan Modra <amodra@gmail.com>
Date:   Thu Oct 7 11:19:53 2021 +1030

    PR28423, use-after-free in objdump

    XCOFF archives use a bi-directional linked list for file members.  So
    one member points to both the previous member and the next member.
    Members may not be sequentially ordered in the file.  This of course
    is over-engineered nonsense and an attractive target for fuzzers.
    (There is even a free list of members!)  The testcase in PR28423 is an
    XCOFF archive with one member pointing to itself, which results in
    lots of bad behaviour.  For example, "ar t" never terminates.

    The use-after-free with "objdump -r" happens like this:  The first
    archive element is opened, its symbols are read and "canonicalized"
    for objdump, then relocations are read and printed.  Those relocations
    use the canonicalized symbols, and also happen to be cached by the
    coff bfd backend support.  objdump frees the symbols.  The next
    archive element is then opened.  This must be done before the first
    element is closed, because finding the next element uses data held in
    the currect element.  Unfortunately the next element happens to be the
    original, so we aren't opening, we're reopening a bfd which has cached
    data.  When the relocations are printed they use the cached copy
    containing references to the freed canonical symbols.

    This patch adds a little sanity checking to the XCOFF "open next
    archive file" support, so that it rejects archive members pointing at
    themselves.  That is sufficient to cure this problem.  Anything more
    is overkill.  If someone deliberately fuzzes an XCOFF archive with an
    element loop then reports an "ar" bug when it runs forever, they will
    find their bug report closed WONTFIX.

            PR 28423
            * coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied
            by member name in areltdata.extra_size.
            (_bfd_xcoff_openr_next_archived_file): Sanity check nextoff.
            * coff64-rs6000.c (xcoff64_openr_next_archived_file): Call
            _bfd_xcoff_openr_next_archived_file.

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