[Bug binutils/29914] New: Asan reported heap-buffer-overflow of objdump at dwarf.c:744 in fetch_indexed_value()
https://sourceware.org/bugzilla/show_bug.cgi?id=29914 Bug ID: 29914 Summary: Asan reported heap-buffer-overflow of objdump at dwarf.c:744 in fetch_indexed_value() Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: 13579and24680 at gmail dot com Target Milestone: --- Created attachment 14522 --> https://sourceware.org/bugzilla/attachment.cgi?id=14522&action=edit Generated by my fuzzer and afl-tmin I found a heap-buffer-overflow with my fuzzer on objdump compiled with Asan. It didn't crash objdump compiled without Asan this time. - # version $ ./binutils-gdb_asan/binutils/objdump --version GNU objdump (GNU Binutils) 2.39.50.20221216 Copyright (C) 2022 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. - # git log $ git log --oneline -1 fa501b69309 (HEAD -> master, origin/master, origin/HEAD) Fix a potential illegal memory access when parsing corrupt DWARF information. - # make $ git clone git://sourceware.org/git/binutils-gdb.git $ cd binutils-gdb $ ./configure CFLAGS='-fsanitize=address -g3' CXXFALGS='-fsanitize=address -g3' $ make - # ASAN report $ ./binutils-gdb_asan/binutils/objdump -W poc ./binutils-gdb_asan/binutils/objdump: warning: poc has a section extending past end of file = ==2765629==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000b1 at pc 0x55a51efcd89b bp 0x7ffdbdd5d8e0 sp 0x7ffdbdd5d8d0 READ of size 1 at 0x602000b1 thread T0 #0 0x55a51efcd89a in byte_get_little_endian /home/a13579/fuzz_binutils-gdb/binutils-gdbnew/binutils-gdb_asan/binutils/elfcomm.c:119 #1 0x55a51ef40ca3 in fetch_indexed_value dwarf.c:744 #2 0x55a51ef4e156 in read_and_display_attr_value dwarf.c:2879 #3 0x55a51ef50363 in read_and_display_attr dwarf.c:3443 #4 0x55a51ef53f4d in process_debug_info dwarf.c:4044 #5 0x55a51ef91ad9 in load_separate_debug_files dwarf.c:11982 #6 0x55a51ef3b95b in dump_bfd objdump.c:5520 #7 0x55a51ef3c688 in display_object_bfd objdump.c:5715 #8 0x55a51ef3c9b9 in display_any_bfd objdump.c:5801 #9 0x55a51ef3ca33 in display_file objdump.c:5822 #10 0x55a51ef3e36d in main objdump.c:6230 #11 0x7f123ccf7082 in __libc_start_main ../csu/libc-start.c:308 #12 0x55a51ef2239d in _start (/home/a13579/fuzz_binutils-gdb/binutils-gdbnew/binutils-gdb_asan/binutils/objdump+0x13b39d) 0x602000b1 is located 0 bytes to the right of 1-byte region [0x602000b0,0x602000b1) allocated by thread T0 here: #0 0x7f123cfd8808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 #1 0x55a51f31d620 in xmalloc xmalloc.c:149 #2 0x55a51ef34b25 in load_specific_debug_section objdump.c:4216 #3 0x55a51ef352a6 in load_debug_section objdump.c:4317 #4 0x55a51ef91aa0 in load_separate_debug_files dwarf.c:11976 #5 0x55a51ef3b95b in dump_bfd objdump.c:5520 #6 0x55a51ef3c688 in display_object_bfd objdump.c:5715 #7 0x55a51ef3c9b9 in display_any_bfd objdump.c:5801 #8 0x55a51ef3ca33 in display_file objdump.c:5822 #9 0x55a51ef3e36d in main objdump.c:6230 #10 0x7f123ccf7082 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/a13579/fuzz_binutils-gdb/binutils-gdbnew/binutils-gdb_asan/binutils/elfcomm.c:119 in byte_get_little_endian Shadow bytes around the buggy address: 0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff8000: fa fa fd fa fa fa 00 04 fa fa 00 04 fa fa 00 04 =>0x0c047fff8010: fa fa 00 01 fa fa[01]fa fa fa fa fa fa fa fa fa 0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone:
[Bug binutils/29915] New: bfdio.c does not compile with mingw.org's MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=29915 Bug ID: 29915 Summary: bfdio.c does not compile with mingw.org's MinGW Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: eliz at gnu dot org Target Milestone: --- CC bfdio.lo bfdio.c: In function '_bfd_real_fopen': bfdio.c:130:28: error: implicit declaration of function '___lc_codepage_func' [-Werror=implicit-function-declaration] 130 |const unsigned int cp = ___lc_codepage_func(); |^~~ This happens because the proper prototype of ___lc_codepage_func is defined under a condition that is only valid for MinGW64: #if defined(__MINGW64_VERSION_MAJOR) && __MINGW64_VERSION_MAJOR < 9 /* This prototype was added to locale.h in version 9.0 of MinGW-w64. */ _CRTIMP unsigned int __cdecl ___lc_codepage_func(void); #endif mingw.org's MinGW doesn't define __MINGW64_VERSION_MAJOR, and it lacks the prototype of ___lc_codepage_func in all of its versions. Therefore, I suggest the following fix to satisfy both flavors of MinGW: --- bfd/bfdio.c~0 2022-12-17 03:47:10.0 +0200 +++ bfd/bfdio.c 2022-12-17 16:45:38.06775 +0200 @@ -31,8 +31,10 @@ #include #endif -#if defined(__MINGW64_VERSION_MAJOR) && __MINGW64_VERSION_MAJOR < 9 -/* This prototype was added to locale.h in version 9.0 of MinGW-w64. */ +#if (defined(__MINGW64_VERSION_MAJOR) && __MINGW64_VERSION_MAJOR < 9) \ + || (defined(__MINGW32__) && !defined(__MINGW64_VERSION_MAJOR)) +/* This prototype was added to locale.h in version 9.0 of MinGW-w64, + and is absent from all versions of mingw.org's MinGW. */ _CRTIMP unsigned int __cdecl ___lc_codepage_func(void); #endif -- You are receiving this mail because: You are on the CC list for the bug.
Compilation problem in bfdio.c using mingw.org's MinGW
When building the latest snapshot of GDB 13 with mingw.org's MinGW tools, I bumped into the following compilation error: CC bfdio.lo bfdio.c: In function '_bfd_real_fopen': bfdio.c:130:28: error: implicit declaration of function '___lc_codepage_func' [-Werror=implicit-function-declaration] 130 |const unsigned int cp = ___lc_codepage_func(); |^~~ This happens because the proper prototype of ___lc_codepage_func is defined under a condition that is only valid for MinGW64: #if defined(__MINGW64_VERSION_MAJOR) && __MINGW64_VERSION_MAJOR < 9 /* This prototype was added to locale.h in version 9.0 of MinGW-w64. */ _CRTIMP unsigned int __cdecl ___lc_codepage_func(void); #endif mingw.org's MinGW doesn't define __MINGW64_VERSION_MAJOR, and it lacks the prototype of ___lc_codepage_func in all of its versions. Therefore, I suggest the following fix to satisfy both flavors of MinGW: --- bfd/bfdio.c~0 2022-12-17 03:47:10.0 +0200 +++ bfd/bfdio.c 2022-12-17 16:45:38.06775 +0200 @@ -31,8 +31,10 @@ #include #endif -#if defined(__MINGW64_VERSION_MAJOR) && __MINGW64_VERSION_MAJOR < 9 -/* This prototype was added to locale.h in version 9.0 of MinGW-w64. */ +#if (defined(__MINGW64_VERSION_MAJOR) && __MINGW64_VERSION_MAJOR < 9) \ + || (defined(__MINGW32__) && !defined(__MINGW64_VERSION_MAJOR)) +/* This prototype was added to locale.h in version 9.0 of MinGW-w64, + and is absent from all versions of mingw.org's MinGW. */ _CRTIMP unsigned int __cdecl ___lc_codepage_func(void); #endif
