Hi,

I think most of us know that the dwarf2read.c pretty much assumes that 
the DWARF input is okay. The reporter of this bug used a binary fuzzer 
to corrupt the DWARF info:

<1><569>: Abbrev Number: 16 (DW_TAG_enumeration_type)
     <56a>   DW_AT_byte_size   : 4
     <56b>   DW_AT_decl_file   : 17
     <56c>   DW_AT_decl_line   : 73
     <56d>   DW_AT_sibling     : <0xb12>
  <2><571>: Abbrev Number: 17 (DW_TAG_enumerator)
     <572>   DW_AT_name        : (indirect string, offset: 0xf14): 
_SC_ARG_MAX
     <576>   DW_AT_const_value : 0

[snip]

<2><a8c>: Abbrev Number: 17 (DW_TAG_enumerator)
     <a8d>   DW_AT_name        : (indirect string, offset: 0x9b7): 
_SC_LEVEL3_CACHE_ASSOC
     <a91>   DW_AT_const_value : 2243
  <2><a93>: Abbrev Number: 12 (DW_TAG_array_type)
     <a94>   DW_AT_type        : <0x114>
     <a98>   DW_AT_sibling     : <0x761101c4>
  <3><a9c>: Abbrev Number: 10 (DW_TAG_member)
     <a9d>   DW_AT_name        : (indirect string, offset: 0x1c50000): 
<offset is
  too big>
     <aa1>   DW_AT_decl_file   : 17
     <aa2>   DW_AT_decl_line   : 2539
     <aa4>   DW_AT_type        : <0x1c60000>
     <aa8>   DW_AT_data_member_location: 17

As you can see, the sibling for DIE 0xa93 points of to la-la land. This 
causes skip_one_die to crash, since it never validates whether the 
offset of the sibling is contained within the current readers's input 
buffer. This function does check, however, whether the offset is negative.

This patch essentially adds the counterpoint check and a beginning at 
some tests for catch-all "corrupt" DWARF.

Keith

ChangeLog
2014-03-20  Keith Seitz  <keiths@redhat.com>

	PR gdb/15827
	* dwarf2read.c (skip_one_die): Check that all relative-offset
	sibling DIEs fall within range of the current reader's buffer.
	(read_partial_die): Likewise.

testsuite/ChangeLog
2014-03-20  Keith Seitz  <keiths@redhat.com>

	PR gdb/15827
	* gdb.dwarf2/corrupt.c: New file.
	* gdb.dwarf2/corrupt.exp: New file.