bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/4110] Broken object file crashes nm


From: cvs-commit at gcc dot gnu.org
Subject: [Bug binutils/4110] Broken object file crashes nm
Date: Fri, 31 Jan 2020 00:31:43 +0000

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

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

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

commit 327301a4604da40da264c554daa8c1e97aa2fbe2
Author: Alan Modra <address@hidden>
Date:   Fri Jan 31 00:53:59 2020 +1030

    OOM in setup_group

    We alloc, seek and read using section sizes in object files.  Fuzzed
    objects can have silly sizes, but that's OK if the system supports
    memory over-commit.  The read fails because we hit EOF and that
    usually results in a graceful exit.

    But if we memset before the read then the invalid size results in
    attempting to write to a huge number of memory pages, and an eventual
    Out Of Memory after probably swapping like crazy.  So don't memset.
    There really isn't a need to clear the section contents anyway.  All
    bytes are written with a good object file by the read and following
    loop converting section index in target order to ELF section header
    pointer, and the only untidy bytes are the 4 bytes past the group
    flags when pointers are 8 bytes.  Those don't matter but the patch
    clears them for anyone poking around in a debugger.  On error paths
    it's as good to free section contents as it is to clear them.

    Noticed when looking at PR4110 fourth test case.

        PR 4110
        * elf.c (setup_group): Don't clear entire section contents,
        just the padding after group flags.  Release alloc'd memory
        after a seek or read failure.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]