[Bug binutils/22416] New: heap-buffer-overflow in bfd_getl16
https://sourceware.org/bugzilla/show_bug.cgi?id=22416 Bug ID: 22416 Summary: heap-buffer-overflow in bfd_getl16 Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jgj212 at gmail dot com Target Milestone: --- Created attachment 10578 --> https://sourceware.org/bugzilla/attachment.cgi?id=10578&action=edit heap-buffer-overflow-in-bfd_getl16 Hi: I found a heap-buffer-overflow in bfd_getl16 about objdump 2.29.1. Here is the asan-output: ==5178==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61700371 at pc 0x0064bc77 bp 0x7ffcbd59cd00 sp 0x7ffcbd59ccf8 READ of size 1 at 0x61700371 thread T0 #0 0x64bc76 in bfd_getl16 binutils-2.29.1/bfd/libbfd.c:505:11 #1 0x8b7cbf in _bfd_pei_swap_debugdir_in binutils-2.29.1/bfd/peigen.c:1121:22 #2 0x894164 in pe_bfd_read_buildid binutils-2.29.1/bfd/./peicode.h:1353:7 #3 0x88cc2f in pe_bfd_object_p binutils-2.29.1/bfd/./peicode.h:1497:7 #4 0x64538c in bfd_check_format_matches binutils-2.29.1/bfd/format.c:311:14 #5 0x51785f in display_object_bfd binutils-2.29.1/binutils/./objdump.c:3601:7 #6 0x517769 in display_any_bfd binutils-2.29.1/binutils/./objdump.c:3692:5 #7 0x5172aa in display_file binutils-2.29.1/binutils/./objdump.c:3713:3 #8 0x516b04 in main binutils-2.29.1/binutils/./objdump.c:4015:6 #9 0x7f5074958f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) #10 0x41b74b in _start (binutils-2.29.1/binutils/objdump+0x41b74b) 0x61700371 is located 1 bytes to the right of 752-byte region [0x61700080,0x61700370) allocated by thread T0 here: #0 0x4df116 in malloc asan_malloc_linux.cc:66 #1 0x64b51e in bfd_malloc binutils-2.29.1/bfd/libbfd.c:193:9 #2 0x6415cb in bfd_get_full_section_contents binutils-2.29.1/bfd/compress.c:248:21 #3 0x658d04 in bfd_malloc_and_get_section binutils-2.29.1/bfd/section.c:1640:10 #4 0x89403a in pe_bfd_read_buildid binutils-2.29.1/bfd/./peicode.h:1339:8 #5 0x88cc2f in pe_bfd_object_p binutils-2.29.1/bfd/./peicode.h:1497:7 #6 0x64538c in bfd_check_format_matches binutils-2.29.1/bfd/format.c:311:14 #7 0x51785f in display_object_bfd binutils-2.29.1/binutils/./objdump.c:3601:7 #8 0x517769 in display_any_bfd binutils-2.29.1/binutils/./objdump.c:3692:5 #9 0x5172aa in display_file binutils-2.29.1/binutils/./objdump.c:3713:3 #10 0x516b04 in main binutils-2.29.1/binutils/./objdump.c:4015:6 #11 0x7f5074958f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) SUMMARY: AddressSanitizer: heap-buffer-overflow binutils-2.29.1/bfd/libbfd.c:505:11 in bfd_getl16 Shadow bytes around the buggy address: 0x0c2e7fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2e7fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2e7fff8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2e7fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2e7fff8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c2e7fff8060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa 0x0c2e7fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2e7fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2e7fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2e7fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2e7fff80b0: 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: f1 Stack mid redzone: f2 Stack right redzone: f3 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 Left alloca redzone: ca Right alloca redzone:cb ==5178==ABORTING Credit: ADLab of VenusTech -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 Jan Beulich changed: What|Removed |Added CC||jbeulich at novell dot com --- Comment #4 from Jan Beulich --- The adjustment done to intelok.s is was wrong here: MASM accepts that code, and so should gas. I certainly can agree that accepting _anything_ between the colons was too lax, but the change has definitely introduced a regression. Please fix, and for future Intel syntax changes please also follow the fundamental model of awaiting maintainer approval. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #5 from Jan Beulich --- (I can't, btw, see how to change the status of the bug back from RESOLVED FIXED, or how to re-assign it. Pretty strange a UI limitation as it seems.) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #6 from H.J. Lu --- (In reply to Jan Beulich from comment #4) > The adjustment done to intelok.s is was wrong here: MASM accepts that code, > and so should gas. I certainly can agree that accepting _anything_ between > the colons was too lax, but the change has definitely introduced a > regression. Please fix, and for future Intel syntax changes please also > follow the fundamental model of awaiting maintainer approval. If gas doesn't allow multiple segment registers in AT&T syntax, it shouldn't allow them in Intel syntax. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #7 from Jan Beulich --- (In reply to H.J. Lu from comment #6) > If gas doesn't allow multiple segment registers in AT&T syntax, it > shouldn't allow them in Intel syntax. I can only keep telling you that I view maximum possible compatibility with MASM more important that compatibility between the under-specified (or should I say not specified at all) AT&T syntax. As the maintainer of the Intel syntax code I would not have approved the patch in the shape you've committed it. Please fix it to avoid the need to revert. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #8 from H.J. Lu --- (In reply to Jan Beulich from comment #7) > (In reply to H.J. Lu from comment #6) > > If gas doesn't allow multiple segment registers in AT&T syntax, it > > shouldn't allow them in Intel syntax. > > I can only keep telling you that I view maximum possible compatibility with > MASM more important that compatibility between the under-specified (or > should I say not specified at all) AT&T syntax. As the maintainer of the > Intel syntax code I would not have approved the patch in the shape you've > committed it. Please fix it to avoid the need to revert. My understanding is that gas can't assemble many assembly codes which accept MASM. It is more important for gas to be consistent with itself. In the case of "fs:gs:[eax]", you can replace it with "fs:[eax]" to get the same output. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #9 from Jan Beulich --- (In reply to H.J. Lu from comment #8) > (In reply to Jan Beulich from comment #7) > > (In reply to H.J. Lu from comment #6) > > > If gas doesn't allow multiple segment registers in AT&T syntax, it > > > shouldn't allow them in Intel syntax. > > > > I can only keep telling you that I view maximum possible compatibility with > > MASM more important that compatibility between the under-specified (or > > should I say not specified at all) AT&T syntax. As the maintainer of the > > Intel syntax code I would not have approved the patch in the shape you've > > committed it. Please fix it to avoid the need to revert. > > My understanding is that gas can't assemble many assembly codes which > accept MASM. Of course, hence me saying "maximum possible compatibility" (instead of saying "full"). > It is more important for gas to be consistent with itself. That's a bogus goal imo: Different assembly syntax can naturally result in apparent inconsistencies. > In the case of "fs:gs:[eax]", you can replace it with > "fs:[eax]" to get the same output. In straight line code yes. But what if a first override is hidden deep in a macro you can't or don't want to modify, but you need to add an override to in one special case? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #10 from H.J. Lu --- (In reply to Jan Beulich from comment #9) > > > It is more important for gas to be consistent with itself. > > That's a bogus goal imo: Different assembly syntax can naturally result in Not to me. > apparent inconsistencies. > > > In the case of "fs:gs:[eax]", you can replace it with > > "fs:[eax]" to get the same output. > > In straight line code yes. But what if a first override is hidden deep in a > macro you can't or don't want to modify, but you need to add an override to > in one special case? Do you have a real example? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #11 from Jan Beulich --- (In reply to H.J. Lu from comment #10) > > > In the case of "fs:gs:[eax]", you can replace it with > > > "fs:[eax]" to get the same output. > > > > In straight line code yes. But what if a first override is hidden deep in a > > macro you can't or don't want to modify, but you need to add an override to > > in one special case? > > Do you have a real example? No, I don't. But I don't assume you have a real example of someone having used something like fs:foo:[ebx] either, to support your original change. The reporter's example, as he states, did not result in bad code being generated (and for that case accepting the code was the intended behavior). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #12 from H.J. Lu --- (In reply to Jan Beulich from comment #11) > (In reply to H.J. Lu from comment #10) > > > > In the case of "fs:gs:[eax]", you can replace it with > > > > "fs:[eax]" to get the same output. > > > > > > In straight line code yes. But what if a first override is hidden deep in > > > a > > > macro you can't or don't want to modify, but you need to add an override > > > to > > > in one special case? > > > > Do you have a real example? > > No, I don't. But I don't assume you have a real example of someone having > used something like fs:foo:[ebx] either, to support your original change. > The reporter's example, as he states, did not result in bad code being > generated (and for that case accepting the code was the intended behavior). Someone bothered enough to open a bug report with a testcase. That is good enough for me. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #13 from Uros Bizjak --- (In reply to H.J. Lu from comment #12) > Someone bothered enough to open a bug report with a testcase. That is > good enough for me. gcc generated non-sensical output in -asm=intel mode, and assembler failed to detect obvious error. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21874] x86: Multiple segment registers in the address are not detected with -masm=intel
https://sourceware.org/bugzilla/show_bug.cgi?id=21874 --- Comment #14 from Uros Bizjak --- (In reply to Uros Bizjak from comment #13) > (In reply to H.J. Lu from comment #12) > > > Someone bothered enough to open a bug report with a testcase. That is > > good enough for me. > > gcc generated non-sensical output in -asm=intel mode, and assembler failed > to detect obvious error. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81641 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22419] New: binary format generated by LD is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=22419 Bug ID: 22419 Summary: binary format generated by LD is incorrect Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: critical Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hackish at gmail dot com Target Milestone: --- Created attachment 10579 --> https://sourceware.org/bugzilla/attachment.cgi?id=10579&action=edit Test case LD as shown in this example for the NEC V850 processor generates bogus jump instructions resolving addresses when used to output in format=binary. The object files are generated correctly, and the linker exhibits this behavior only using binary mode. As the example shows, it generates correct code if the output is done in ELF, then changed into a binary using objcopy. This example was run on 2.17.50, but others also verified the problem in a variety of versions up to 2.30. The example is for the NEC V850 processor, but others reported similar problems on other architectures. Extract the attached archive, and run: gmake clean all Expected output is: rm -f one.o firmware.o a.out a.elf a.bin v850-elf-as -mv850e1 -c firmware.s -o firmware.o v850-elf-as -mv850e1 -c one.s -o one.o v850-elf-ld -nostdlib --no-check-sections -Map=a.map -T one.lnk -o a.elf v850-elf-ld -nostdlib --no-check-sections -Map=a.map --oformat binary -T one.lnk -o a.bin v850-elf-objcopy -O binary a.elf a.out Results going direct to binary hexdump -s 0x4E608 -n 28 a.bin 004e608 3640 1234 3e40 5678 c784 fffb 004e618 3640 1234 3e40 5678 004e624 Results with elf as an intermediate: hexdump -s 0x4E608 -n 28 a.out 004e608 3640 1234 3e40 5678 ffbb c77c 004e618 3640 1234 3e40 5678 004e624 Result should have been: 004e608 3640 1234 3e40 5678 ffbb c77c 004e618 3640 1234 3e40 5678 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
