[Bug binutils/27370] New: [readelf] warning when processing abbrev with DW_FORM_ref_sig8
https://sourceware.org/bugzilla/show_bug.cgi?id=27370 Bug ID: 27370 Summary: [readelf] warning when processing abbrev with DW_FORM_ref_sig8 Product: binutils Version: 2.37 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- ... $ g++ gdb/testsuite/gdb.cp/cpexprs.cc -gdwarf-5 -fdebug-types-section $ ~/binutils/install/bin/readelf -w a.out > READELF readelf: Warning: Unexpected form 20 encountered whilst finding abbreviation for type ... The form 20 is actually a hex, so the warning could add a 0x prefix to make that clear. The form 0x20 is: ... DW_FORM (DW_FORM_ref_sig8, 0x20) ... Putting the warning together with the output, we have: ... <2><1839>: Abbrev Number: 48 (DW_TAG_member) <183a> DW_AT_name: (indirect string, offset: 0x2065): _sbuf <183e> DW_AT_decl_file : 4 <183f> DW_AT_decl_line : 158 <1840> DW_AT_type: <0x1858>readelf: Warning: Unexpected form 20 encountered whilst finding abbreviation for type <1844> DW_AT_data_member_location: 8 ... and the referenced type looks like: ... <1><1858>: Abbrev Number: 52 (DW_TAG_pointer_type) <1859> DW_AT_byte_size : 8 <185a> DW_AT_type: signature: 0xa8df1933f740ec32 ... with abbrev: ... 52 DW_TAG_pointer_type[no children] DW_AT_byte_sizeDW_FORM_data1 DW_AT_type DW_FORM_ref_sig8 DW_AT value: 0 DW_FORM value: 0 ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27371] New: [readelf] .debug_rnglists section header not parsed
https://sourceware.org/bugzilla/show_bug.cgi?id=27371 Bug ID: 27371 Summary: [readelf] .debug_rnglists section header not parsed Product: binutils Version: 2.37 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- ... $ g++ gdb/testsuite/gdb.cp/cpexprs.cc -gdwarf-5 -fdebug-types-section $ ~/binutils/install/bin/readelf -w a.out Contents of the .debug_rnglists section: Offset BeginEnd readelf: Error: Invalid range list entry type 126 000c 004008c8 004013f1 0017 004013f2 00401407 ... Looking with llvm-dwarfdump: ... .debug_rnglists contents: range list header: length = 0x047e, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x ranges: [0x004008c8, 0x004013f1) [0x004013f2, 0x00401407) ... The entry type 126 is 0x7e in hex (which occurs in the length field of the header). Looks like the section header is not parsed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27377] New: /usr/bin/ld.bfd: section .note.ABI-tag VMA [0000000000400190,00000000004001af] overlaps section .bss VMA [00000000000adc00,00000000004af3ff]
https://sourceware.org/bugzilla/show_bug.cgi?id=27377
Bug ID: 27377
Summary: /usr/bin/ld.bfd: section .note.ABI-tag VMA
[00400190,004001af] overlaps section
.bss VMA [000adc00,004af3ff]
Product: binutils
Version: 2.37 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: mliska at suse dot cz
Target Milestone: ---
The test-case is taken from grub2:
$ cat 1.c
int main()
{
return 0;
}
$ cat 2.S
.bss
.space (1 << 22)
$ gcc 1.c 2.S -Wl,-N -Wl,-Ttext,0 -static -Wl,--build-id=none -fuse-ld=bfd
/usr/bin/ld.bfd: section .note.ABI-tag VMA [00400190,004001af]
overlaps section .bss VMA [000adc00,004af3ff]
collect2: error: ld returned 1 exit status
I believe ld should not make the 2 sections to overlap.
gold is even worse, it crashes:
$ gcc 1.c 2.S -Wl,-N -Wl,-Ttext,0 -static -Wl,--build-id=none -fuse-ld=gold
/usr/bin/ld.gold: internal error in set_offset, at ../../gold/output.cc:4780
collect2: error: ld returned 1 exit status
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/27355] SEGFAULT in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27355 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com CC||nickc at redhat dot com Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-08 --- Comment #1 from Nick Clifton --- Hi Sirus, Thanks for reporting this problem. I have a patch which I am testing locally, and I will update this PR if it passes all of my checks. > Our investigation suggests this is a critical bug. I would disagree with that categorization. The bug is not triggered by well formed assembler directives, but only by fuzzed ones. The assembler generated by gcc for example should never trigger this problem. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Steven Noonan changed: What|Removed |Added CC||steven at uplinklabs dot net -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27355] SEGFAULT in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27355 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=80b652efa2e969d865d06e1a4aec16b4dcd9f435 commit 80b652efa2e969d865d06e1a4aec16b4dcd9f435 Author: Nick Clifton Date: Mon Feb 8 18:31:21 2021 + Fix an illegal memory access when parsing a corrupt assembler file. PR 27355 * dwarf2dbg.c (allocate_filename_to_slot): Allocate the dirs array if it has not already been created. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27355] SEGFAULT in dwarf2dbg.c
https://sourceware.org/bugzilla/show_bug.cgi?id=27355 --- Comment #3 from Sirus Shahini --- > I would disagree with that categorization. The bug is not triggered by well > formed assembler directives, but only by fuzzed ones. The assembler > generated by gcc for example should never trigger this problem. By critical I was referring to the consequences of a successful exploitation through a crafted assembly input. Of course a normal compile of a C/C++ file won't cause that much of a trouble but in security assessment of a bug, how a malicious input is given to the vulnerable program isn't usually related to its security impact. Thanks, Sirus -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27381] New: out of memory with .incbin "directory/"
https://sourceware.org/bugzilla/show_bug.cgi?id=27381 Bug ID: 27381 Summary: out of memory with .incbin "directory/" Product: binutils Version: unspecified Status: UNCONFIRMED Severity: minor Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: gnu at niksoggia dot it Target Milestone: --- Created attachment 13210 --> https://sourceware.org/bugzilla/attachment.cgi?id=13210&action=edit fail early when .incbin argument is a directory Dear binutils developers, we all know that .incbin expect files and not directories, but in this case gas shows a misleading error message: $ echo '.incbin "/etc/"' >will_it_fail.S && as will_it_fail.S as: out of memory allocating 9223372036854841503 bytes after a total of 270336 bytes There is no easy way out: fopen() fseek() and ftell() are happy with directories. The easiest C89 way out of the problem I can think of now is that read() in not happy with directories. For a better error message we could waste some I/O time before trying to allocate 2^63 bytes, here is my idea. Regards, -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27382] New: build failure: Fails if fileno() is a macro due to a missing FILE * cast
https://sourceware.org/bugzilla/show_bug.cgi?id=27382 Bug ID: 27382 Summary: build failure: Fails if fileno() is a macro due to a missing FILE * cast Product: binutils Version: 2.36.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sourcewarebugz at kyber dot fi Target Milestone: --- Created attachment 13211 --> https://sourceware.org/bugzilla/attachment.cgi?id=13211&action=edit Fix to a missing cast in fileno() usage binutils/objcopy.c copy_file fileno() usage is missing a cast and hence the build fails on systems where fileno() is a macro. Patch is included. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27382] build failure: Fails if fileno() is a macro due to a missing FILE * cast
https://sourceware.org/bugzilla/show_bug.cgi?id=27382 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The binutils-2_36-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7651a4871c225925ffdfda0a8c91a6ed370cd9a1 commit 7651a4871c225925ffdfda0a8c91a6ed370cd9a1 Author: Alan Modra Date: Tue Feb 9 13:32:36 2021 +1030 PR27382, build failure if fileno() is a macro PR 27382 * objcopy.c (copy_file): Use bfd_stat. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27382] build failure: Fails if fileno() is a macro due to a missing FILE * cast
https://sourceware.org/bugzilla/show_bug.cgi?id=27382 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #2 from Alan Modra --- Fixed again. We lost the fix for this bug in reverting smart_rename changes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27384] New: Invalid free() in _IO_new_file_close_it
https://sourceware.org/bugzilla/show_bug.cgi?id=27384 Bug ID: 27384 Summary: Invalid free() in _IO_new_file_close_it Product: binutils Version: 2.37 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sirus.shahini at gmail dot com Target Milestone: --- Created attachment 13213 --> https://sourceware.org/bugzilla/attachment.cgi?id=13213&action=edit Sample input Hello, Our fuzzer found a heap corruption in 'fileops.c'. A crashing input that triggers an invalud free() has been attached. To reproduce, try to assemble the input with: as -a -- You are receiving this mail because: You are on the CC list for the bug.
