j2k_write_eoc doesn't verify that numresolutions > 0

[GoogleCodeExporter]

From http://bugs.ghostscript.com/show_bug.cgi?id=693171#c3 :

The 590 file does not trigger the j2k_read_cox function so tccp->numresolutions
remains set at its default value of 0, this in turn means that when we reach
the end of codestream marker j2k_read_eoc is called.

As the first tile is decoded in j2k_read_eoc, there is a call to
tcd_malloc_decode_tile which uses the zero numresolution value to allocate some
memory, given the lack of error checking, later code then accesses the contents
of  the uninitialized memory and mayhem ensues.

------

A potential patch can be found at 
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=29a16f87849a874cd872fc
8e2beab2b3986eea51;hp=514595fc2cc84f51efdef563cf7a35a0050902e5

Please contact one of the Artifex developers if you need access to an image 
triggering these conditions.

Original issue reported on code.google.com by zeniko on 15 Jul 2012 at 7:15

• Merged into: #156

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 25 Feb 2014 at 3:51

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

The proposed patch seems to only apply to branch 1.5

Original comment by mathieu.malaterre on 26 Feb 2014 at 4:12

• Added labels: Milestone-Release1.5.2
• Removed labels: Milestone-Release2.1

[GoogleCodeExporter]

Looks like this has been patched already in r1729

closing

Original comment by mathieu.malaterre on 26 Mar 2014 at 3:31

• Changed state: Fixed

[GoogleCodeExporter]

Well clearly issue 159 is a dup of issue 159 marking as such

Original comment by mathieu.malaterre on 26 Mar 2014 at 3:32

• Changed state: Duplicate