Crash when applying the component definition box

[GoogleCodeExporter]

In openjp2/jp2.c (trunk r2322), there is a crash in the opj_jp2_apply_cdef() 
function.  This function iterates over all image components applying changes to 
the data based on the values contained in the component definition box.  Line 
981 in jp2.c checks for an asoc value of 0, which indicates that the component 
is associated with the image as a whole, and continues.

According to the JPEG2000 Part 1 specification, a value of 65535 is also valid, 
which indicates that the component is not associated with any color.  When the 
asoc value is 65535, a crash occurs on line 991 when the image component array 
is accessed at index 65534, which does not exist.

In addition to checking for an asoc value of 0, opj_jp2_apply_cdef() should 
also check for the valid value of 65535.

Original issue reported on code.google.com by opticks....@gmail.com on 11 Apr 2013 at 2:32

[GoogleCodeExporter]

Is it possible to upload one image with this defect?

winfried

Original comment by szukw...@arcor.de on 12 Apr 2013 at 12:47

[GoogleCodeExporter]

Unfortunately, I do not have a sample file that can be publicly distributed.  
The crash typically only occurs on jp2 files with more than 3 image components 
where the asoc value for the 4th or greater component is set to 65535.  Thanks!

Original comment by opticks....@gmail.com on 15 Apr 2013 at 2:29

[GoogleCodeExporter]

The attached patch fixes the crash, and allows the images to display properly.  
However, I am not sure if other code needs to be modified to fully address the 
problem.  Thanks!

Original comment by opticks....@gmail.com on 15 Apr 2013 at 3:09

Attachments:

• openjpeg_r2322.patch

[GoogleCodeExporter]

Ok, no file. Could you please use openjpeg-1.5 with the same file?

winfried

Original comment by szukw...@arcor.de on 16 Apr 2013 at 4:59

[GoogleCodeExporter]

Both of the openjpeg-1.5 and openjpeg-2.0 release versions crash on the same 
file.  I first tried these versions before switching to the trunk to ensure the 
problem still existed before creating this issue.

The changes made in the trunk patch that I attached in my previous comment can 
also be made in the jp2_apply_cdef() function in openjpeg-1.5, which is nearly 
identical to opj_jp2_apply_cdef() in the current trunk.  Thanks!

Original comment by opticks....@gmail.com on 16 Apr 2013 at 1:31

[GoogleCodeExporter]

I confirm this patch is necessary in openjpeg-2.0. I just spent one hour 
figuring that this was this very issue...

The image is mentionned in http://trac.osgeo.org/gdal/ticket/5317 and available 
at 
http://hdds.usgs.gov/hdds2/adhoc/disaster/200908_Hurricane_Test/data/SATELLITE/N
ON_INGESTED/GDAL/test3/openjpeg/20100216_a_abc6_0924_0483_hr4.jp2?system=hdds

It is a 4 band 16-bit image.

Original comment by even.rou...@gmail.com on 5 Dec 2013 at 10:13

[GoogleCodeExporter]

Actually I can propose an extended version of the patch that adds new checks in 
case the image is corrupted

Original comment by even.rou...@gmail.com on 5 Dec 2013 at 10:28

Attachments:

• issue_218.patch

[GoogleCodeExporter]

I cannot access 20100216_a_abc6_0924_0483_hr4.jp2, it says I need to register. 
The image is 404Mo, which clearly makes it impossible to redistribute.
We would need something smaller for the openjepg data test

Original comment by mathieu.malaterre on 24 Feb 2014 at 2:59

[GoogleCodeExporter]

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

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

I'll apply the patch as-is, please reopen this issue if this does not work for 
you. I do not have access to material to reproduce issue anyway.

Original comment by mathieu.malaterre on 27 Feb 2014 at 5:20

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r2507.

Original comment by mathieu.malaterre on 27 Feb 2014 at 5:21

• Changed state: Fixed