Bug 15213 - process_extended_line_op overflow
Summary: process_extended_line_op overflow
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.23
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-28 13:35 UTC by Paul Marinescu
Modified: 2013-03-27 10:07 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
valgrind objdump -Wl extlineop.o (482 bytes, application/x-object)
2013-02-28 13:35 UTC, Paul Marinescu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Marinescu 2013-02-28 13:35:42 UTC
Created attachment 6907 [details]
valgrind objdump -Wl extlineop.o

process_extended_line_op (dwarf.c) may overflow its unsigned char *data argument. This can happen because it only detects the end of the buffer by its contents, which are not previously validated. The function could perform better error checking if it would also receive the allocated size of the buffer.

An example input triggering an overflow is attached, along with valgrind output:

==6131== Memcheck, a memory error detector
==6131== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==6131== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==6131== Command: /home/pdm/binutils/binutils/objdump -Wl extlineop.o
==6131== 

extlineop.o:     file format elf64-x86-64

Raw dump of debug contents of section .debug_line:

  Offset:                      0x0
  Length:                      62
  DWARF Version:               2
  Prologue Length:             35
  Minimum Instruction Length:  1
  Initial value of 'is_stmt':  1
  Line Base:                   1
  Line Range:                  1
  Opcode Base:                 16

 Opcodes:
  Opcode 1 has 0 args
  Opcode 2 has 1 args
  Opcode 3 has 1 args
  Opcode 4 has 1 args
  Opcode 5 has 1 args
  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 args
  Opcode 10 has 0 args
  Opcode 11 has 0 args
  Opcode 12 has 1 args
  Opcode 13 has 0 args
  Opcode 14 has 0 args
  Opcode 15 has 0 args

 The Directory Table is empty.

 The File Name Table:
  Entry	Dir	Time	Size	Name
  1	0	0	0	file1.txt

 Line Number Statements:
  Extended opcode 2: set Address to 0x4
  Advance Line by 3 to 4
  Copy
  Copy
  Extended opcode 2: set Address to 0x8
==6131== Invalid read of size 1
==6131==    at 0x40BC80: display_debug_lines (dwarf.c:423)
==6131==    by 0x407D55: dump_dwarf_section (objdump.c:2364)
==6131==    by 0x445D8B: bfd_map_over_sections (section.c:1330)
==6131==    by 0x4068A2: dump_dwarf (objdump.c:2411)
==6131==    by 0x406CCF: dump_bfd (objdump.c:3242)
==6131==    by 0x407477: display_any_bfd (objdump.c:3329)
==6131==    by 0x4079B7: display_file.part.3 (objdump.c:3404)
==6131==    by 0x4084C6: main (objdump.c:3393)
==6131==  Address 0x4c2bab2 is 0 bytes after a block of size 66 alloc'd
==6131==    at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==6131==    by 0x443575: bfd_malloc (libbfd.c:183)
==6131==    by 0x4541C7: bfd_get_full_section_contents (compress.c:181)
==6131==    by 0x407AD3: load_specific_debug_section (objdump.c:2264)
==6131==    by 0x407D3C: dump_dwarf_section (objdump.c:2361)
==6131==    by 0x445D8B: bfd_map_over_sections (section.c:1330)
==6131==    by 0x4068A2: dump_dwarf (objdump.c:2411)
==6131==    by 0x406CCF: dump_bfd (objdump.c:3242)
==6131==    by 0x407477: display_any_bfd (objdump.c:3329)
==6131==    by 0x4079B7: display_file.part.3 (objdump.c:3404)
==6131==    by 0x4084C6: main (objdump.c:3393)
==6131== 
  Extended opcode 0: UNKNOWN: length 1 [ 00]

==6131== 
==6131== HEAP SUMMARY:
==6131==     in use at exit: 0 bytes in 0 blocks
==6131==   total heap usage: 119 allocs, 119 frees, 65,486 bytes allocated
==6131== 
==6131== All heap blocks were freed -- no leaks are possible
==6131== 
==6131== For counts of detected and suppressed errors, rerun with: -v
==6131== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Comment 1 Nick Clifton 2013-03-27 10:07:32 UTC
Hi Paul,

This problem is already fixed in the mainline sources.  (Probably by the patch for 15206).

Cheers
  Nick