Bug#774037: rzip: segmentation fault

[Jakub Wilk]

Package: rzip
Version: 2.1-2
Usertags: afl

rzip crashes when unpacking the attached (slightly corrupted) file:

$ rzip -d crash.rz
Partial read!? asked for 12517376 bytes but got 174
Segmentation fault


This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl

Disclaimer: I don't have spare CPU cycles, so I fuzzed only till the
first crash (which took only a few seconds). It's likely that extensive
fuzzing would uncover more interesting crashers. I'd encourage rzip
maintainers to perform fuzzing with AFL on their own. :-)

-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages rzip depends on:
ii libbz2-1.0 1.0.6-7+b2
ii libc6 2.19-13

[наб]

Control: found -1 2.1-4.1
Control: tags -1 + confirmed upstream

Can't repro segfault, but can repro
$ rm crash; valgrind rzip -d crash.rz
==4059613== Memcheck, a memory error detector
==4059613== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==4059613== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==4059613== Command: rzip -d crash.rz
==4059613==
Partial read!? asked for 12517376 bytes but got 174
==4059613== Syscall param write(buf) points to uninitialised byte(s)
==4059613== at 0x4973240: write (write.c:26)
==4059613== by 0x10AFAF: ??? (in /usr/bin/rzip)
==4059613== by 0x109627: ??? (in /usr/bin/rzip)
==4059613== by 0x48A2249: (below main) (libc_start_call_main.h:58)
==4059613== Address 0x4a5e1d0 is 0 bytes inside a block of size 191 alloc'd
==4059613== at 0x48407B4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4059613== by 0x10AF80: ??? (in /usr/bin/rzip)
==4059613== by 0x109627: ??? (in /usr/bin/rzip)
==4059613== by 0x48A2249: (below main) (libc_start_call_main.h:58)
==4059613==
==4059613== Use of uninitialised value of size 8
==4059613== at 0x10C406: ??? (in /usr/bin/rzip)
==4059613== by 0x10AFD2: ??? (in /usr/bin/rzip)
==4059613== by 0x109627: ??? (in /usr/bin/rzip)
==4059613== by 0x48A2249: (below main) (libc_start_call_main.h:58)
==4059613==
Bad checksum 0x00000000 - expected 0xbe1b2745
Fatal error - exiting
==4059613==
==4059613== HEAP SUMMARY:
==4059613== in use at exit: 12,517,499 bytes in 5 blocks
==4059613== total heap usage: 6 allocs, 1 frees, 12,517,690 bytes allocated
==4059613==
==4059613== LEAK SUMMARY:
==4059613== definitely lost: 0 bytes in 0 blocks
==4059613== indirectly lost: 0 bytes in 0 blocks
==4059613== possibly lost: 0 bytes in 0 blocks
==4059613== still reachable: 12,517,499 bytes in 5 blocks
==4059613== suppressed: 0 bytes in 0 blocks
==4059613== Rerun with --leak-check=full to see details of leaked memory
==4059613==
==4059613== Use --track-origins=yes to see where uninitialised values come from
==4059613== For lists of detected and suppressed errors, rerun with: -s
==4059613== ERROR SUMMARY: 192 errors from 2 contexts (suppressed: 0 from 0)
which looks like it would segfault with a different memory layout.