Created attachment 10890 [details] Crashing test case (objdump) After some fuzz testing I found a crashing test case. Version: 2.30 Command: objdump -x -D -S -s -G -g -e -t -T -r -R objdump_hoobr_pex64_get_unwind_info ASAN Context: ==20442==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e00000dff7 at pc 0x000000977e90 bp 0x7fffdace5b80 sp 0x7fffdace5b70 READ of size 1 at 0x60e00000dff7 thread T0 #0 0x977e8f in pex64_get_unwind_info XYZ/binutils-2.30.0/bfd/pei-x86_64.c:113 #1 0x977e8f in pex64_dump_xdata XYZ/binutils-2.30.0/bfd/pei-x86_64.c:348 #2 0x977e8f in pex64_bfd_print_pdata_section XYZ/binutils-2.30.0/bfd/pei-x86_64.c:720 #3 0x97887d in pex64_print_all_pdata_sections XYZ/binutils-2.30.0/bfd/pei-x86_64.c:745 #4 0x61c56b in bfd_map_over_sections XYZ/binutils-2.30.0/bfd/section.c:1397 #5 0x9787e9 in pex64_bfd_print_pdata XYZ/binutils-2.30.0/bfd/pei-x86_64.c:759 #6 0x99abcd in _bfd_pex64_print_private_bfd_data_common XYZ/binutils-2.30.0/bfd/pex64igen.c:2908 #7 0x963640 in pe_print_private_bfd_data XYZ/binutils-2.30.0/bfd/peicode.h:336 #8 0x42009c in dump_bfd_private_header objdump.c:2966 #9 0x42009c in dump_bfd objdump.c:3559 #10 0x421a77 in display_object_bfd objdump.c:3658 #11 0x421a77 in display_any_bfd objdump.c:3747 #12 0x40ea81 in display_file objdump.c:3768 #13 0x40ea81 in main objdump.c:4070 #14 0x7fd3b68ca82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #15 0x411ca8 in _start (/usr/local/bin/objdump+0x411ca8) 0x60e00000dff7 is located 0 bytes to the right of 151-byte region [0x60e00000df60,0x60e00000dff7) allocated by thread T0 here: #0 0x7fd3b6f10602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x601d1a in bfd_malloc XYZ/binutils-2.30.0/bfd/libbfd.c:193 #2 0x61200000bfb7 (<unknown module>) SUMMARY: AddressSanitizer: heap-buffer-overflow XYZ/binutils-2.30.0/bfd/pei-x86_64.c:113 pex64_get_unwind_info Shadow bytes around the buggy address: 0x0c1c7fff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9be0: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 00 =>0x0c1c7fff9bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[07]fa 0x0c1c7fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1c7fff9c40: 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 Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe ==20442==ABORTING
Hi Kamil, I could not reproduce this bug, but I think that might be because of the recent fix for PR 22113. Please could you recheck and see if the problem still exists for you. Cheers Nick
Closing as 2.30 is so old