bug-binutils
[Top][All Lists]
Advanced

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

[Bug binutils/24938] New: Null Pointer Dereference in debug.c:debug_writ


From: andreafioraldi at gmail dot com
Subject: [Bug binutils/24938] New: Null Pointer Dereference in debug.c:debug_write_type() with malformed MS-DOS executable
Date: Sun, 25 Aug 2019 20:17:43 +0000

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

            Bug ID: 24938
           Summary: Null Pointer Dereference in debug.c:debug_write_type()
                    with malformed MS-DOS executable
           Product: binutils
           Version: 2.32
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: andreafioraldi at gmail dot com
  Target Milestone: ---

Created attachment 11964
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11964&action=edit
MS-DOS executable that causes the bug when opened with -g

My fuzzer generated a file that causes a Null Pointer Dereference in objdump
release version 2.52.
The bug is confirmed also for the 2.32.51.20190825 version from git.

The bug appears when using the -g flag.

Seems that the debug_write_type routine assume that the type parameter is not
NULL and doesn't performs checks on it.
>From Valgrind (running valgrind ./objdgump -g crash.exe):

==1166== Invalid read of size 4
==1166==    at 0x18DF11: debug_write_type (debug.c:2425)
==1166==    by 0x18E6DD: debug_write_type (debug.c:2535)
==1166==    by 0x18E1E7: debug_write_type (debug.c:2558)
==1166==    by 0x18E1E7: debug_write_type (debug.c:2558)
==1166==    by 0x18EB0E: debug_write_name (debug.c:2373)
==1166==    by 0x1907D8: debug_write (debug.c:2350)
==1166==    by 0x18C824: print_debugging_info (prdbg.c:319)
==1166==    by 0x16B611: dump_bfd (objdump.c:3833)
==1166==    by 0x16BC47: display_object_bfd (objdump.c:3883)
==1166==    by 0x16BC47: display_any_bfd (objdump.c:3973)
==1166==    by 0x16E433: display_file (objdump.c:3994)
==1166==    by 0x16788C: main (objdump.c:4304)
==1166==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

I attach a minimized test file (419 bytes) to reproduce the issue.

I've just found the bug and I will investigate further if you need.
Thanks for the attention,
Andrea Fioraldi

-- 
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]