[Bug tools/24116] A Heap-buffer-overflow problem was discovered in the function print_debug_line_section in readelf.c

2019-02-01 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=24116

--- Comment #6 from Mark Wielaard  ---
(In reply to wcventure from comment #5)
> Created attachment 11581 [details]
> Regression

Running with:
 valgrind -q src/readelf --debug-dump=line ./RegressionPOC
will produce:

==57142== Invalid read of size 2
==57142==at 0x12F431: print_debug_line_section (readelf.c:8807)
==57142==by 0x11E2C0: print_debug (readelf.c:11212)
==57142==by 0x1201C0: process_elf_file (readelf.c:998)
==57142==by 0x1201C0: process_dwflmod (readelf.c:760)
==57142==by 0x486D6A0: dwfl_getmodules (dwfl_getmodules.c:86)
==57142==by 0x11414F: process_file (readelf.c:868)
==57142==by 0x111C33: main (readelf.c:350)
==57142==  Address 0x4f20a83 is 0 bytes after a block of size 339 alloc'd
==57142==at 0x483577F: malloc (vg_replace_malloc.c:299)
==57142==by 0x48A0358: convert_data (elf_getdata.c:157)
==57142==by 0x48A0358: __libelf_set_data_list_rdlock (elf_getdata.c:447)
==57142==by 0x48A0547: __elf_getdata_rdlock (elf_getdata.c:554)
==57142==by 0x484EFB0: check_section (dwarf_begin_elf.c:167)
==57142==by 0x484F522: global_read (dwarf_begin_elf.c:310)
==57142==by 0x484F522: dwarf_begin_elf (dwarf_begin_elf.c:445)
==57142==by 0x486F9A7: load_dw (dwfl_module_getdwarf.c:1342)
==57142==by 0x486FBCB: find_dw (dwfl_module_getdwarf.c:1392)
==57142==by 0x486FBCB: dwfl_module_getdwarf (dwfl_module_getdwarf.c:1447)
==57142==by 0x11DD4A: print_debug (readelf.c:10943)
==57142==by 0x1201C0: process_elf_file (readelf.c:998)
==57142==by 0x1201C0: process_dwflmod (readelf.c:760)
==57142==by 0x486D6A0: dwfl_getmodules (dwfl_getmodules.c:86)
==57142==by 0x11414F: process_file (readelf.c:868)
==57142==by 0x111C33: main (readelf.c:350)
==57142== 

Fixed by:

commit cad9595592730fd8c9d0d9236d38f62ec8cfbcef
Author: Mark Wielaard 
Date:   Fri Feb 1 09:08:14 2019 +0100

readelf: Check there is enough data to read DWARF line opcodes arguments.

When reading the debug_line opcode arguments we have to make sure there
is enough data to read the arguments (if there are any(.

The similar code in dwarf_getsrclines already had these checks.

https://sourceware.org/bugzilla/show_bug.cgi?id=24116

Signed-off-by: Mark Wielaard 

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

2019-02-01 Thread ksd.selvakumar at yahoo dot in
https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #6 from selva  ---
(In reply to Mark Wielaard from comment #5)
> (In reply to selva from comment #4)
> > Created attachment 11548 [details]
> > Uclibc full testsuite log
> > 
> > Attaching the full test suite log.
> 
> BTW. It is easier to just attache the tests/test-suite.log.
> But I am afraid there still isn't enough to figure out what is going wrong.
> Maybe the config.log could show a bit more.
> 
> Please run one of the segfaulting tests under gdb and get a backtrace to
> show what is really going on.

Mmm., Tried to run the test with gdb but i get "no stack" Please share me the
steps to get the backtrace if you have any.

# ./run-elfputzdata.sh 
Segmentation fault
# 
# gdb --args bash ./run-elfputzdata.sh 
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-unkown-linux-uclibcgnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bash...done.
(gdb) run
Starting program: /bin/bash ./run-elfputzdata.sh
/root/elfutils-0.173/tests/test-subr.sh: line 64:  3679 Segmentation fault 
diff -u $outfile -
[Inferior 1 (process 3670) exited with code 0213]
(gdb) 
(gdb) backtrace 
No stack.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

2019-02-01 Thread ksd.selvakumar at yahoo dot in
https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #7 from selva  ---
Created attachment 11582
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11582&action=edit
config.log

Attached the config.log.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libdw/24140] A Heap-buffer-overflow problem was discovered in the function __libdw_next_unit in dwarf_nextcu.c in libdw

2019-02-01 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=24140

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mark at klomp dot org
 Resolution|--- |FIXED

--- Comment #1 from Mark Wielaard  ---
Replicated under valgrind:
$ valgrind -q eu-nm -C ./POC.unit 
src/nm: ./POC.unit: entry size in section 2 `.debug_info' is not what we expect
==15242== Invalid read of size 8
==15242==at 0x4850940: __libdw_next_unit (dwarf_nextcu.c:168)
==15242==by 0x4850C24: dwarf_next_unit (dwarf_nextcu.c:46)
==15242==by 0x4850C24: dwarf_nextcu (dwarf_nextcu.c:294)
==15242==by 0x10E73B: get_local_names (nm.c:627)
==15242==by 0x10E73B: show_symbols (nm.c:1285)
==15242==by 0x10FCEA: handle_elf (nm.c:1578)
==15242==by 0x110482: process_file (nm.c:374)
==15242==by 0x10D70D: main (nm.c:249)
==15242==  Address 0x525481a is 26 bytes inside a block of size 32 alloc'd
==15242==at 0x483577F: malloc (vg_replace_malloc.c:299)
==15242==by 0x48A0358: convert_data (elf_getdata.c:157)
==15242==by 0x48A0358: __libelf_set_data_list_rdlock (elf_getdata.c:447)
==15242==by 0x48A0547: __elf_getdata_rdlock (elf_getdata.c:554)
==15242==by 0x484EFB0: check_section (dwarf_begin_elf.c:167)
==15242==by 0x484F522: global_read (dwarf_begin_elf.c:310)
==15242==by 0x484F522: dwarf_begin_elf (dwarf_begin_elf.c:445)
==15242==by 0x10E690: show_symbols (nm.c:1243)
==15242==by 0x10FCEA: handle_elf (nm.c:1578)
==15242==by 0x110482: process_file (nm.c:374)
==15242==by 0x10D70D: main (nm.c:249)
==15242== 
==15242== Invalid read of size 2
==15242==at 0x485094B: __libdw_next_unit (dwarf_nextcu.c:168)
==15242==by 0x4850C24: dwarf_next_unit (dwarf_nextcu.c:46)
==15242==by 0x4850C24: dwarf_nextcu (dwarf_nextcu.c:294)
==15242==by 0x10E73B: get_local_names (nm.c:627)
==15242==by 0x10E73B: show_symbols (nm.c:1285)
==15242==by 0x10FCEA: handle_elf (nm.c:1578)
==15242==by 0x110482: process_file (nm.c:374)
==15242==by 0x10D70D: main (nm.c:249)
==15242==  Address 0x5254822 is 2 bytes after a block of size 32 alloc'd
==15242==at 0x483577F: malloc (vg_replace_malloc.c:299)
==15242==by 0x48A0358: convert_data (elf_getdata.c:157)
==15242==by 0x48A0358: __libelf_set_data_list_rdlock (elf_getdata.c:447)
==15242==by 0x48A0547: __elf_getdata_rdlock (elf_getdata.c:554)
==15242==by 0x484EFB0: check_section (dwarf_begin_elf.c:167)
==15242==by 0x484F522: global_read (dwarf_begin_elf.c:310)
==15242==by 0x484F522: dwarf_begin_elf (dwarf_begin_elf.c:445)
==15242==by 0x10E690: show_symbols (nm.c:1243)
==15242==by 0x10FCEA: handle_elf (nm.c:1578)
==15242==by 0x110482: process_file (nm.c:374)
==15242==by 0x10D70D: main (nm.c:249)
==15242== 

We do check we can read the initial unit lenght (4 bytes), but then fail to
check if we can read any extended length for a DWARF64 unit. We also fail to
check whether we can read the actual version or (DWARF5) unit type. After we
know the version and unit type we do sanity check the full header length (we
cannot really know before reading those three fields at least).

Fixed by:

commit e8f8dc465a1fa496aa627a330886c0f70f98d4c0
Author: Mark Wielaard 
Date:   Fri Feb 1 14:03:38 2019 +0100

libdw: Check there is enough space for CU 64bit length, version and type.

We only checked we could read the initial length and after knowing the
version and type whether the unit header was the right size. Also check
there are at least enough bytes to read the 64bit length, version and
unit type bytes.

https://sourceware.org/bugzilla/show_bug.cgi?id=24140

Signed-off-by: Mark Wielaard 

-- 
You are receiving this mail because:
You are on the CC list for the bug.