bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

unshar crash


From: Bruno Haible
Subject: unshar crash
Date: Wed, 27 Jul 2005 14:05:57 +0200
User-agent: KMail/1.5

Hi,

Here's a simple way to crash 'unshar': Go to the sharutils-4.4 source
directory, then do

$ shar --version
shar (GNU sharutils) 4.4
Copyright (C) 1994, 1995, 1996 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ unshar --version
unshar (GNU sharutils) 4.4
Copyright (C) 1994, 1995, 1996, 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ shar NEWS > NEWS.shar
shar: Saving NEWS (text)
$ unshar NEWS.shar
*** glibc detected *** unshar: realloc(): invalid pointer: 0x0804b6ac ***
======= Backtrace: =========
/lib/libc.so.6[0x400938be]
/lib/libc.so.6(__libc_realloc+0x1d7)[0x400965f7]
/lib/libc.so.6[0x40096d21]
/lib/libc.so.6(__libc_realloc+0x3c)[0x4009645c]
unshar(vfprintf+0xb70)[0x8049754]
/lib/libc.so.6(__libc_start_main+0x99)[0x40045949]
unshar(_IO_getc+0x5d)[0x8048dc1]
======= Memory map: ========
08048000-0804b000 r-xp 00000000 03:07 483185     /packages/gnu/bin/unshar
0804b000-0804c000 rw-p 00002000 03:07 483185     /packages/gnu/bin/unshar
0804c000-08075000 rwxp 00000000 00:00 0
40000000-4001b000 r-xp 00000000 03:03 16466      /lib/ld-2.3.90.so
4001b000-4001c000 rw-p 0001a000 03:03 16466      /lib/ld-2.3.90.so
4001c000-4001d000 rw-p 00000000 00:00 0
40030000-40144000 r-xp 00000000 03:03 16598      /lib/libc-2.3.90.so
40144000-4014c000 rw-p 00113000 03:03 16598      /lib/libc-2.3.90.so
4014c000-4014e000 rw-p 00000000 00:00 0
4014e000-40158000 r-xp 00000000 03:03 12128      /lib/libgcc_s.so.1
40158000-40159000 rw-p 00009000 03:03 12128      /lib/libgcc_s.so.1
bfffd000-c0000000 rwxp fffff000 00:00 0
Aborted

Here's valgrind's report about this crash:

$ valgrind --tool=memcheck --num-callers=20 --leak-check=yes 
--leak-resolution=high --show-reachable=yes \
  unshar NEWS.shar
==12815== Memcheck, a memory error detector for x86-linux.
==12815== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==12815== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==12815== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==12815== For more details, rerun with: -v
==12815== 
==12815== Conditional jump or move depends on uninitialised value(s)
==12815==    at 0x804965E: main (unshar.c:438)
==12815== 
==12815== Conditional jump or move depends on uninitialised value(s)
==12815==    at 0x1B909F9C: realloc (vg_replace_malloc.c:187)
==12815==    by 0x8049753: main (unshar.c:446)
==12815== 
==12815== Invalid free() / delete / delete[]
==12815==    at 0x1B90A01A: realloc (vg_replace_malloc.c:196)
==12815==    by 0x8049753: main (unshar.c:446)
==12815==  Address 0x804B6AC is not stack'd, malloc'd or (recently) free'd
unshar: allocate file name buffer: Cannot allocate memory
==12815== 
==12815== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 13 from 1)
==12815== malloc/free: in use at exit: 128 bytes in 1 blocks.
==12815== malloc/free: 5 allocs, 4 frees, 266 bytes allocated.
==12815== For counts of detected errors, rerun with: -v
==12815== searching for pointers to 1 not-freed blocks.
==12815== checked 110720 bytes.
==12815== 
==12815== 
==12815== 128 bytes in 1 blocks are still reachable in loss record 1 of 1
==12815==    at 0x1B909575: malloc (vg_replace_malloc.c:130)
==12815==    by 0x8049DBE: xmalloc (xmalloc.c:87)
==12815==    by 0x8049D3B: xgetcwd (xgetcwd.c:73)
==12815==    by 0x8049488: main (unshar.c:376)
==12815== 
==12815== LEAK SUMMARY:
==12815==    definitely lost: 0 bytes in 0 blocks.
==12815==      possibly lost: 0 bytes in 0 blocks.
==12815==    still reachable: 128 bytes in 1 blocks.
==12815==         suppressed: 0 bytes in 0 blocks.

This bug is quite fresh: it was not present in sharutils-4.3.78 (but
before, unshar.c:main():name_buffer was vulnerable to buffer overflow -
not much better...)

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]