lzip-bug
[Top][All Lists]
Advanced

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

[Lzip-bug] silent data corruption by lzip-1.2-pre1


From: John Reiser
Subject: [Lzip-bug] silent data corruption by lzip-1.2-pre1
Date: Thu, 04 Dec 2008 14:57:57 -0800
User-agent: Thunderbird 2.0.0.18 (X11/20081119)

Here is an example of lzip-1.2-pre1 corrupting data silently.

$ cp COPYING foo
$ ls -l foo   # approx. 35KB file
-r--r--r-- 1 jreiser jreiser 35068 2008-12-04 14:04 foo
$ rm -f foo.lz   # insure no conflict over filename
$ ./lzip -s30 foo   # compress
$ echo $?
0   # previous command "./lzip -s30 foo" succeeded
$ ls -l foo.lz   # but output is only 28 bytes long
-r--r--r-- 1 jreiser jreiser 28 2008-12-04 14:04 foo.lz
$ od -Ax -tx4 foo.lz   # document the actual output
000000 50495a4c 83001e00 fffffbff 000000c0
000010 00000000 00000000 00000000
00001c
$ ./lzip -d foo.lz   # decompress
$ echo $?
0   # previous command "./lzip -d foo.lz" succeeded
$ ls -l foo   # but output is an empty file
-r--r--r-- 1 jreiser jreiser 0 2008-12-04 14:04 foo

The environment:
$ uname -a
Linux host.domain 2.6.27.5-41.fc9.i686 #1 SMP Thu Nov 13 20:52:14 EST 2008 i686 
athlon i386 GNU/Linux
$ ldd ./lzip
        linux-gate.so.1 =>  (0x00110000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x037ce000)
        libm.so.6 => /lib/libm.so.6 (0x005cc000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00df0000)
        libc.so.6 => /lib/libc.so.6 (0x00461000)
        /lib/ld-linux.so.2 (0x00441000)
$ rpm -qf /usr/lib/libstdc++.so.6
libstdc++-4.3.0-8.i386
$ rpm -qf /lib/libc.so.6
glibc-2.8-8.i686
$ g++ --version
g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
$


Obviously "-s30" is the culprit.
However, the buglist is impressive:
   Bad input parameter was validated anyway.
   User documentation "./lzip --help" is incorrect for "-s".
      Is it size, or length, or log2 of size or length?
      What is the range of legal values?
   C++ runtime was used unsafely: __builtin_vec_new(0x80001111)
   Missing end-to-end sanity check after compression of file.
      Embedded CRC32 of 0x00000000 does not equal CRC32 of input file.
      Embedded length of 0 does not equal actual length of input file.
      Files (input and output) can be checked more strictly than streams
      because *stat() and *seek() succeed for files.
   No automated test of "-s".

-- 
John Reiser




reply via email to

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