Summary: | app-arch/gzip: crash on bad input | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tavis Ormandy (RETIRED) <taviso> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | trivial | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://dev.gentoo.org/~taviso/files/gzip-crash.gz | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Gzip file which cannot be decompressed after applying the patch |
Description
Tavis Ormandy (RETIRED)
2005-05-31 00:01:57 UTC
the comment just about huft_build() says: /* Given a list of code lengths and a maximum table size, make a set of tables to decode that set of codes. Return zero on success, one if the given code set is incomplete (the tables are still built in this case), two if the input is invalid (all zero length codes or an oversubscribed set of lengths), and three if not enough memory. */ the case you're looking at is for 'all zero length codes' which means it should return 2 instead of 0 ... that does fix the crash so i've added gzip-1.3.5-r8 with the fix forgot to close ... Created attachment 67422 [details]
Gzip file which cannot be decompressed after applying the patch
The patch causes gzip -d to return "gzip: stdin: invalid compressed
data--format violated" when decompressing dynamic huffman encoded files which
don't have any matches, such as the one I am attaching. When there are no
matches, then the distance huffman tree will have all zero length entries and
huft_build() will return 2, even though this is valid according to the gzip
spec, RFC1951. Without the patch the file decompresses correctly. I am
working on finding a fix for both problems now.
|