After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695513 - GIF: too much input data, ignoring extra
GIF: too much input data, ignoring extra
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
2.8.4
Other All
: Normal minor
: 2.8
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2013-03-09 17:47 UTC by Richard Kettlewell
Modified: 2013-03-12 07:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GIF that triggers the bug (43 bytes, image/gif)
2013-03-09 17:47 UTC, Richard Kettlewell
Details

Description Richard Kettlewell 2013-03-09 17:47:12 UTC
Created attachment 238463 [details]
GIF that triggers the bug

Here is a small GIF (also attached):

00000000  47 49 46 38 39 61 02 00  02 00 f0 00 31 00 00 00  |GIF89a......1...|
00000010  01 01 01 21 f9 04 04 00  00 00 00 2c 00 00 00 00  |...!.......,....|
00000020  02 00 02 00 00 02 02 44  5c 00 3b                 |.......D\.;|
0000002b

The compressed image data is the two bytes 44 5c and consists of the
codes 4(clear), 0, 1, 6, 5(end), packed into 3-bit fields.

Loading this GIF into Gimp produces this message on stderr:

  GIF: too much input data, ignoring extra...

In this case it is a false positive.

The reason is the final 'return code & 255' in LZWReadByte().  This
only runs when GetCode() has returned -1 to indicate the end of the
image data.  In this case a negative value should also be returned
from LZWReadByte(), to indicate the end of the data.  Other parts of
LZWReadByte() do this and it's what ReadImage() expects.

ANDing with 255 means that 255 is instead returned to ReadImage(),
resulting in the message above.

Suggested fix:

--- a/plug-ins/common/file-gif-load.c
+++ b/plug-ins/common/file-gif-load.c
@@ -862,7 +862,7 @@ LZWReadByte (FILE *fd,
         return (*--sp) & 255;
     }
 
-  return code & 255;
+  return -1;
 }
 
 static gint32
Comment 1 Mukund Sivaraman 2013-03-12 07:34:39 UTC
This is a bug in our code. GIMP doesn't correctly parse a 2x2 1-bit checkerboard pattern GIF image that it saved.

The patch suggested in comment #0 is an incorrect fix. GetCode() has the bug, where it incorrectly thinks it has run out of input bits. With a fixed GetCode(), LZWReadByte() correctly parses the following End of Information code.

I'll attach a patch shortly.
Comment 2 Mukund Sivaraman 2013-03-12 07:47:56 UTC
Pushed to master branch:

commit f86655bb1fcf356524c1894096f4866633cc7666
Author: Mukund Sivaraman <muks@banu.com>
Date:   Tue Mar 12 13:08:14 2013 +0530

    file-gif-load: Fix incorrect out-of-input-bits condition (#695513)
    
    GetCode() erroneously assumes that it has run out of input bits, because
    it's off by 1 in its size calculation. At the end of the block, if the
    End-of-Information code is exactly at the block boundary, it calculates
    that it needs to read an extra bit, and tries to read beyond the end of
    the block. It fails then, and the End-of-Information code is not
    processed, and other warnings/errors are generated.


Pushed to gimp-2-8 branch:

commit af88c4a6c943eb5db04fa3eea00befb7442a1e58
Author: Mukund Sivaraman <muks@banu.com>
Date:   Tue Mar 12 13:08:14 2013 +0530

    file-gif-load: Fix incorrect out-of-input-bits condition (#695513)
    
    GetCode() erroneously assumes that it has run out of input bits, because
    it's off by 1 in its size calculation. At the end of the block, if the
    End-of-Information code is exactly at the block boundary, it calculates
    that it needs to read an extra bit, and tries to read beyond the end of
    the block. It fails then, and the End-of-Information code is not
    processed, and other warnings/errors are generated.
    (cherry picked from commit f86655bb1fcf356524c1894096f4866633cc7666)

Resolving as FIXED, milestone 2.8.