[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/20059] New: _bfd_elf_copy_link_hash_symbol_type used when !elf_b
From: |
pipcet at gmail dot com |
Subject: |
[Bug ld/20059] New: _bfd_elf_copy_link_hash_symbol_type used when !elf_backend_relocate_section, segfault, access past allocated size |
Date: |
Sun, 08 May 2016 13:35:37 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=20059
Bug ID: 20059
Summary: _bfd_elf_copy_link_hash_symbol_type used when
!elf_backend_relocate_section, segfault, access past
allocated size
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: minor
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pipcet at gmail dot com
Target Milestone: ---
Created attachment 9240
--> https://sourceware.org/bugzilla/attachment.cgi?id=9240&action=edit
proposed patch
I'm working on an experimental target which currently does not define
elf_backend_relocate_section.
Inconsistent macro definitions in elfxx-target.h are causing segfaults.
The problem I am hitting is that elfxx-target.h contains the following code:
----
#else /* ! defined (elf_backend_relocate_section) */
/* If no backend relocate_section routine, use the generic linker.
Note - this will prevent the port from being able to use some of
the other features of the ELF linker, because the generic hash structure
does not have the fields needed by the ELF linker. In particular it
means that linking directly to S-records will not work. */
#ifndef bfd_elfNN_bfd_link_hash_table_create
#define bfd_elfNN_bfd_link_hash_table_create \
_bfd_generic_link_hash_table_create
#endif
...
#ifndef bfd_elfNN_bfd_copy_link_hash_symbol_type
#define bfd_elfNN_bfd_copy_link_hash_symbol_type \
_bfd_elf_copy_link_hash_symbol_type
#endif
----
which means that link hash table entries will be allocated with type (and size
of) struct bfd_link_hash_entry, but _bfd_elf_copy_link_hash_symbol_type will
cast pointers to such entries to struct elf_link_hash_entry and access
structure elements past the allocated size, resulting in hard-to-reproduce
segfaults due to data corruption when another structure is in memory at that
address.
I don't think we should segfault in that case, and I think the comment I quoted
above is misleading as it stands--the ELF features will appear to work, but
randomly corrupt memory.
I'm not sure whether it is possible to fix this bug without requiring all ELF
backends to define elf_backend_relocate_section, and I'd appreciate advice on
whether I have to do that.
(I'm testing the attached trivial patch, which appears to avoid the segfault
but still results in runnable code.)
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/20059] New: _bfd_elf_copy_link_hash_symbol_type used when !elf_backend_relocate_section, segfault, access past allocated size,
pipcet at gmail dot com <=
- [Bug ld/20059] _bfd_elf_copy_link_hash_symbol_type used when !elf_backend_relocate_section, segfault, access past allocated size, pipcet at gmail dot com, 2016/05/08
- [Bug ld/20059] _bfd_elf_copy_link_hash_symbol_type used when !elf_backend_relocate_section, segfault, access past allocated size, amodra at gmail dot com, 2016/05/09
- [Bug ld/20059] _bfd_elf_copy_link_hash_symbol_type used when !elf_backend_relocate_section, segfault, access past allocated size, pipcet at gmail dot com, 2016/05/09
- [Bug ld/20059] _bfd_elf_copy_link_hash_symbol_type used when !elf_backend_relocate_section, segfault, access past allocated size, cvs-commit at gcc dot gnu.org, 2016/05/09
- [Bug ld/20059] _bfd_elf_copy_link_hash_symbol_type used when !elf_backend_relocate_section, segfault, access past allocated size, amodra at gmail dot com, 2016/05/09