objdump segfaults when dumping library with sources (arm-elf / arm-none-eabi)

[Michael Trensch]

Hi,

First of all I am quite new to compiling binutils, etc. myself and I
don't know if this is a compiler problem, generating wrong debugging
information, or a binutils problem disassembling wrong.

My main problem is then objdump segfaults when dumping library files. I
reproduced this behavior with the Yagarto toolchain and it also happens
there. I first remarked it when dumping my own ARM libraries and thought
that it's my libraries. So I tried it with the compiler / newlib
delivered libraries and saw the same effect. It never crashed so far on
a full-build application in an .elf file.

In my case it was easily reproducible when executing "arm-elf-objdump -S
libc.a".

The last output (before segfault) written was:

---
00000000 <__libc_fini_array>:
extern void _fini (void);

/* Run all the cleanup routines.  */
void
__libc_fini_array (void)
{
   0:
---

I am not very familiar with gdb but I was able to track down the location where it happened.
The function get_map_sym_type() in "opcodes/arm-dis.c" was called with a disassemble info containing 4 sym_tabs, while n was 24. This results in an array out of bound access which may segfault.

When I added validation of the input parameters the segfault was gone (and disassembly for this opcode seems to be skipped).
---
diff -aurN binutils-2.21/opcodes/arm-dis.c binutils-2.21-netx/opcodes/arm-dis.c
--- binutils-2.21/opcodes/arm-dis.c	2010-09-27 09:47:04.000000000 +0000
+++ binutils-2.21-netx/opcodes/arm-dis.c	2011-07-22 11:00:55.000000000 +0000
@@ -4500,6 +4500,8 @@
 		  enum map_type *map_type)
 {
   /* If the symbol is in a different section, ignore it.  */
+  if (n >= info->symtab_size)
+    return FALSE;
   if (info->section != NULL && info->section != info->symtab[n]->section)
     return FALSE;
---

After that I was able to dump the same library but the disassembly was missing.
---
00000000 <__libc_fini_array>:
extern void _fini (void);

/* Run all the cleanup routines.  */
void
__libc_fini_array (void)
{
   0:	e92d4070 	.word	0xe92d4070
...
---

I know that this only cures the symptoms but not the cause. I did not look deeper into the symbol parsing happening before (deep ELF Format knowledge would be needed I assume). Probably someone with a deeper knowledge of the source / parsing can find the real issue with this information.


Does anyone already know about this issue? Is there any workaround for this?


Regards,
Michael