[Top][All Lists]
[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
- [Lzip-bug] silent data corruption by lzip-1.2-pre1,
John Reiser <=