First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 94584
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo's Team for Core System packages <base-system@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Tavis Ormandy (RETIRED) <taviso@gentoo.org>
Add CC:
CC:
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
one.gz Gzip file which cannot be decompressed after applying the patch application/x-tar ssjoholm@aha.com 2005-09-01 09:20 0000 31 bytes Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 94584 depends on: Show dependency tree
Show dependency graph
Bug 94584 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug

Description:   Opened: 2005-05-31 00:01 0000 
A QA test uncovered an input data stream that crashes gzip -d, there's a
testcase in the URL field. Upstream informed, but no response yet.

Perhaps huft_build() should be returning non-zero around line 340 of inflate.c?
At the moment it causes a NULL deref:

...
    336   if (c[0] == n)                /* null input--all zero length codes */
    337   {
    338     *t = (struct huft *)NULL;
    339     *m = 0;
    340     return 0;
    341   }
...

------- Comment #1 From SpanKY 2005-07-02 06:44:09 0000 ------- 
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

------- Comment #2 From SpanKY 2005-07-02 07:44:16 0000 ------- 
forgot to close ...

------- Comment #3 From ssjoholm@aha.com 2005-09-01 09:20:58 0000 ------- 
Created an attachment (id=67422) [edit]
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.
First Last Prev Next    No search results available      Search page      Enter new bug