84523 - Corrupted GIF hangs Mozilla

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P1)

Description

[Daniel Mario Vega (Restore MNG Support --> #18574)]

Some corrupted GIFs images hangs Mozilla

I will upload a testcase

Comment 1

[Daniel Mario Vega (Restore MNG Support --> #18574)]

Attachment: Testcase (Warning! Mozilla hangs)

Comment 2

[Aleksander Adamowski]

Confirming, OS: win2K, Build: win32-talkback 2001060620.
OS: Linux, Build: linux-sea 2001060620
Changing OS to ALL.

Mozilla also starts to consume all the cpu when hung.

Comment 3

[Stuart Parmenter]

->saari

Comment 4

[Warner Young]

Also seems to hang Netscape 4.x, and an image reader app that I wrote.  Wow.

Comment 5

[Warner Young]

I've taken a look at this GIF.  The problem is that after the normal header,
there is a bad datablock.  If you're scanning through the GIF for a terminating
code, you have to skip the datablock by reading all the run lengths from it. 
The run lengths total more than the size of the GIF itself.  At this point,
you'll probably never find the terminating code.

Saari, I apologize for the horrible terminology.  I haven't looked at the source
for libpr0n itself, so I don't know what everything's called in the source.  But
basically, wherever you scan for the terminate code, if you add a check to make
sure the pointer hasn't passed the end of the image, it should fix the hang.

Comment 6

[saari (gone)]

Cool, thanks for the description of the problem!

Comment 7

[saari (gone)]

P1 for 0.9.4

Comment 8

[Stuart Parmenter]

over to nivedita

Comment 9

[Nivedita (gone)]

Attachment: patch file fixing the mozilla hang in case of invalid netscape extension codes in the gif

The reason for mozilla hanging in the given test case, was because the gif in
the given test case has an netscape extension code of 4, while the valid
extension codes as per gif specs are 1 and 2, hence we were handling only the
cases of 1 and 2. Since the other cases were not handled, the next state of gif
was not being set causing it to remain in the same state, resulting mozilla to
hang.

Comment 10

[Stuart Parmenter]

Comment on attachment 65743 [details] [diff] [review]
patch file fixing the mozilla hang in case of invalid netscape extension codes in  the gif

r=pavlov

Comment 11

[tor]

Would it be better to attempt skipping the block "GETN(*q, gif_skip_block)"?

Comment 12

[Stuart Parmenter]

I don't think so.  You don't know the size of the block that you need to skip,
since the extention is bogus.  IE doesn't load the image and actually hangs
Windows Imaging.

Comment 13

[tor]

Actually this is one thing the GIF spec got right - all blocks have a block
size byte as their first entry.  From the spec:

  13. Block Sizes.

  The Block Size field in a block, counts the number of bytes remaining in the
  block, not counting the Block Size field itself, and not counting the Block
  Terminator, if one is to follow.  Blocks other than Data Blocks are intended to
  be of fixed length; the Block Size field is provided in order to facilitate
  skipping them, not to allow their size to change in the future.  Data blocks
  and sub-blocks are of variable length to accommodate the amount of data.

Comment 14

[tor]

Comment on attachment 65743 [details] [diff] [review]
patch file fixing the mozilla hang in case of invalid netscape extension codes in  the gif

sr=tor

Comment 15

[Stuart Parmenter]

checked in fix.

Comment 16

[Terri Preston]

Verified Fixed Win XP build 2002012903, Linux build 2002012909 and Mac OS X
build 2002012808