mips_elf_create_dynamic_relocation can look beyond relocs array end
Sergey Rogozhkin
rogozhkin@niisi.msk.ru
Sat Apr 28 22:35:00 GMT 2007
Hi, list.
The following code in mips_elf_create_dynamic_relocation can look beyond
relocs array end when called in such way:
_bfd_mips_elf_relocate_section -> mips_elf_calculate_relocation ->
mips_elf_create_dynamic_relocation:
outrel[1].r_offset =
_bfd_elf_section_offset (output_bfd, info, input_section,
rel[1].r_offset);
outrel[2].r_offset =
_bfd_elf_section_offset (output_bfd, info, input_section,
rel[2].r_offset);
This code deals with non-standard 64 bit ELF relocations format, but the
problem occurs while linking o32 or n32 objects. If rel points to the
last relocs (_bfd_mips_elf_relocate_section argument) array entry, then
access to rel[1] and rel[2] can cause segfault, or garbage can be read
and passed to _bfd_elf_section_offset, which can cause assertion fail in
_bfd_elf_eh_frame_section_offset. The last is a real case of ld behavior
at least when linking o32 shared libraries using binutils-2.17.50.0.12
(and binutils-2.17.50.0.15 also). Really
mips_elf_create_dynamic_relocation doesn't need rel[1] and rel[2]
records while working in 32 bit mode, maybe it would be better if it
doesn't access them in that case?
Sergey Rogozhkin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mips-create-dynamic-relocation.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20070428/2c1ae687/attachment.ksh>
More information about the Binutils
mailing list