public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug libdw/24140] A Heap-buffer-overflow problem was discovered in the function __libdw_next_unit in dwarf_nextcu.c in libdw
Date: Fri, 01 Feb 2019 13:10:00 -0000	[thread overview]
Message-ID: <bug-24140-10460-CZ8TvNPe3y@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-24140-10460@http.sourceware.org/bugzilla/>

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mark at klomp dot org
         Resolution|---                         |FIXED

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
Replicated under valgrind:
$ valgrind -q eu-nm -C ./POC.unit 
src/nm: ./POC.unit: entry size in section 2 `.debug_info' is not what we expect
==15242== Invalid read of size 8
==15242==    at 0x4850940: __libdw_next_unit (dwarf_nextcu.c:168)
==15242==    by 0x4850C24: dwarf_next_unit (dwarf_nextcu.c:46)
==15242==    by 0x4850C24: dwarf_nextcu (dwarf_nextcu.c:294)
==15242==    by 0x10E73B: get_local_names (nm.c:627)
==15242==    by 0x10E73B: show_symbols (nm.c:1285)
==15242==    by 0x10FCEA: handle_elf (nm.c:1578)
==15242==    by 0x110482: process_file (nm.c:374)
==15242==    by 0x10D70D: main (nm.c:249)
==15242==  Address 0x525481a is 26 bytes inside a block of size 32 alloc'd
==15242==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==15242==    by 0x48A0358: convert_data (elf_getdata.c:157)
==15242==    by 0x48A0358: __libelf_set_data_list_rdlock (elf_getdata.c:447)
==15242==    by 0x48A0547: __elf_getdata_rdlock (elf_getdata.c:554)
==15242==    by 0x484EFB0: check_section (dwarf_begin_elf.c:167)
==15242==    by 0x484F522: global_read (dwarf_begin_elf.c:310)
==15242==    by 0x484F522: dwarf_begin_elf (dwarf_begin_elf.c:445)
==15242==    by 0x10E690: show_symbols (nm.c:1243)
==15242==    by 0x10FCEA: handle_elf (nm.c:1578)
==15242==    by 0x110482: process_file (nm.c:374)
==15242==    by 0x10D70D: main (nm.c:249)
==15242== 
==15242== Invalid read of size 2
==15242==    at 0x485094B: __libdw_next_unit (dwarf_nextcu.c:168)
==15242==    by 0x4850C24: dwarf_next_unit (dwarf_nextcu.c:46)
==15242==    by 0x4850C24: dwarf_nextcu (dwarf_nextcu.c:294)
==15242==    by 0x10E73B: get_local_names (nm.c:627)
==15242==    by 0x10E73B: show_symbols (nm.c:1285)
==15242==    by 0x10FCEA: handle_elf (nm.c:1578)
==15242==    by 0x110482: process_file (nm.c:374)
==15242==    by 0x10D70D: main (nm.c:249)
==15242==  Address 0x5254822 is 2 bytes after a block of size 32 alloc'd
==15242==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==15242==    by 0x48A0358: convert_data (elf_getdata.c:157)
==15242==    by 0x48A0358: __libelf_set_data_list_rdlock (elf_getdata.c:447)
==15242==    by 0x48A0547: __elf_getdata_rdlock (elf_getdata.c:554)
==15242==    by 0x484EFB0: check_section (dwarf_begin_elf.c:167)
==15242==    by 0x484F522: global_read (dwarf_begin_elf.c:310)
==15242==    by 0x484F522: dwarf_begin_elf (dwarf_begin_elf.c:445)
==15242==    by 0x10E690: show_symbols (nm.c:1243)
==15242==    by 0x10FCEA: handle_elf (nm.c:1578)
==15242==    by 0x110482: process_file (nm.c:374)
==15242==    by 0x10D70D: main (nm.c:249)
==15242== 

We do check we can read the initial unit lenght (4 bytes), but then fail to
check if we can read any extended length for a DWARF64 unit. We also fail to
check whether we can read the actual version or (DWARF5) unit type. After we
know the version and unit type we do sanity check the full header length (we
cannot really know before reading those three fields at least).

Fixed by:

commit e8f8dc465a1fa496aa627a330886c0f70f98d4c0
Author: Mark Wielaard <mark@klomp.org>
Date:   Fri Feb 1 14:03:38 2019 +0100

    libdw: Check there is enough space for CU 64bit length, version and type.

    We only checked we could read the initial length and after knowing the
    version and type whether the unit header was the right size. Also check
    there are at least enough bytes to read the 64bit length, version and
    unit type bytes.

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

    Signed-off-by: Mark Wielaard <mark@klomp.org>

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

      reply	other threads:[~2019-02-01 13:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-26  8:16 [Bug libdw/24140] New: " wcventure at 126 dot com
2019-02-01 13:10 ` mark at klomp dot org [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-24140-10460-CZ8TvNPe3y@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).