[Bug ld/29288] New: Redundant '=' before default search path
https://sourceware.org/bugzilla/show_bug.cgi?id=29288
Bug ID: 29288
Summary: Redundant '=' before default search path
Product: binutils
Version: 2.38
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: galaxyking0419 at gmail dot com
Target Milestone: ---
When I build for arm-linux-gnu-binutils using this script
(https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=arm-linux-gnueabihf-binutils),
the search path of result ld has an extra '=' before the search path:
[william@NoteBook ~]$ arm-linux-gnueabihf-ld --verbose | grep SEARCH
SEARCH_DIR("/usr/lib/binutils/arm-linux-gnueabihf");
SEARCH_DIR("=/usr/arm-linux-gnueabihf/lib");
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #12 from Vsevolod Alekseyev --- It's not as bad; a gentleman at the DWARF mailing list pointed out there was a rule in section 7.4 near the end, that the bitness of the same CU's contributions in different sections should be the same: "The 32-bit and 64-bit DWARF format conventions must not be intermixed within a single compilation unit." So reusing the bitness from the corresponding CU in the debug_info is a proper and correct thing to do. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29288] Dependent libraries cannot be found if with default sysroot search dir
https://sourceware.org/bugzilla/show_bug.cgi?id=29288 William Tang changed: What|Removed |Added Summary|Redundant '=' before|Dependent libraries cannot |default search path |be found if with default ||sysroot search dir -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29288] Dependent libraries cannot be found if with default sysroot search dir
https://sourceware.org/bugzilla/show_bug.cgi?id=29288 --- Comment #1 from William Tang --- Okay, the issue is related to sysroot searchdir. For detailed description, please refer to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106088 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #13 from Vsevolod Alekseyev --- Cite: http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-June/004928.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29289] New: display_debug_names: Assertion `name_count == buckets_filled + hash_clash_count' failed
https://sourceware.org/bugzilla/show_bug.cgi?id=29289
Bug ID: 29289
Summary: display_debug_names: Assertion `name_count ==
buckets_filled + hash_clash_count' failed
Product: binutils
Version: 2.39 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: h3xrabbit at gmail dot com
Target Milestone: ---
Created attachment 14176
--> https://sourceware.org/bugzilla/attachment.cgi?id=14176&action=edit
the file caused assertion failed
During fuzzing campaign, I found some files triggered the assertion inside
`binutils/dwarf.c:display_debug_names` with the command:
```
readelf -w file
```
Command output:
```
readelf: Warning: The e_shentsize field in the ELF header is larger than the
size of an ELF section header
readelf: Warning: Section 6 has an out of range sh_link value of 2162688
readelf: Warning: Section 7 has an out of range sh_link value of 638594
readelf: Warning: Section 8 has an out of range sh_link value of 14592
readelf: Warning: Section 10 has an out of range sh_link value of 237568
readelf: Warning: Section 11 has an out of range sh_link value of 4244635647
readelf: Warning: Section 12 has an out of range sh_link value of 457375744
readelf: Warning: Section 14 has an out of range sh_link value of 4278190080
readelf: Warning: The e_phentsize field in the ELF header is larger than the
size of an ELF program header
readelf: Error: Reading 728 bytes extends past end of file for program headers
section '.debug_names' has the NOBITS type - its contents are unreliable.
Contents of the .debug_names section:
readelf: Warning: Debug info is corrupted, .debug_names header at 0 has length
4c457f
readelf: Error: Reading 8192 bytes extends past end of file for .debug_names
section data
Contents of the .debug_names section:
Version 5
readelf: Warning: Padding field of .debug_names must be 0 (found 0x70)
readelf: Warning: Compilation unit count must be >= 1 in .debug_names
Augmentation string: ("")
CU table:
TU table:
Foreign TU table:
Used 1 of 1 bucket.
Out of 0 items there are 0 bucket clashes (longest of 0 entries).
readelf: ../../binutils/dwarf.c:10239: display_debug_names: Assertion
`name_count == buckets_filled + hash_clash_count' failed.
[1]552315 abort ./readelf -w
```
build on latest commit (9544899f2809833729159b0acb414ef7730650d5), with default
config `../configure`
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29290] New: dwarf.c: null pointer dereference
https://sourceware.org/bugzilla/show_bug.cgi?id=29290 Bug ID: 29290 Summary: dwarf.c: null pointer dereference Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: h3xrabbit at gmail dot com Target Milestone: --- Created attachment 14177 --> https://sourceware.org/bugzilla/attachment.cgi?id=14177&action=edit PoC to trigger null pointer dereference During fuzzing campaign, I discovered a null pointer dereference bug in readelf (on the latest commit 9544899f2809833729159b0acb414ef7730650d5) in read_and_display_attr_value(), that can may a denial of service via a crafted file. To reproduce the bug: ``` readelf -w poc ``` ASAN output: ``` = ==527903==ERROR: AddressSanitizer: SEGV on unknown address 0x0078 (pc 0x005da25e bp 0x7ffc9e9d8460 sp 0x7ffc9e9d79e0 T0) ==527903==The signal is caused by a READ memory access. ==527903==Hint: address points to the zero page. #0 0x5da25e in read_and_display_attr_value ../../binutils/dwarf.c:2758:50 #1 0x5cbe63 in display_debug_names ../../binutils/dwarf.c:10369:16 #2 0x57a10c in display_debug_section ../../binutils/readelf.c:16234:18 #3 0x5318a4 in process_section_contents ../../binutils/readelf.c:16330:10 #4 0x51183a in process_object ../../binutils/readelf.c:22368:9 #5 0x501331 in process_file ../../binutils/readelf.c:22791:13 #6 0x4feb82 in main ../../binutils/readelf.c:22862:11 #7 0x7fb874918082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 #8 0x41c4ad in _start (build3/binutils/readelf+0x41c4ad) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /tmp/binutils/build3/binutils/../../binutils/dwarf.c:2758:50 in read_and_display_attr_value ==527903==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
