[gdal-dev] NITF invalid read of 2 bytes causes crash

[Smart, Gary]

This email contained a .zip file attachment. Raytheon does not allow email attachments that are considered likely to contain malicious code. For your protection this attachment has been removed.

If this email is from an unknown source, please simply delete this email.

If this email was expected, and it is from a known sender, you may follow the below suggested instructions to obtain these types of attachments.

+ Instruct the sender to enclose the file(s) in a ".zip" compressed file, and rename the ".zip" compressed file with a different extension, such as, ".rtnzip".  Password protecting the renamed ".zip" compressed file adds an additional layer of protection. When you receive the file, please rename it with the extension ".zip".

Additional instructions and options on how to receive these attachments can be found at:

http://security.it.ray.com/antivirus/extensions.html
http://security.it.ray.com/news/2007/zipfiles.html

Should you have any questions or difficulty with these instructions, please contact the Help Desk at 877.844.4712

---

I have attached a colour NITF image which causes an invalid read within
NITFReadImageLine (nitfimage.c:1661).  This invalid read was detected by
valgrind which I have been using to investigate a crash in my
application - which happens to segfault exactly on this line.  More
often than not, I can read and display this colour image.  Sometimes
though - it crashes my application.  However, even when correctly
displayed, valgrind still reports the invalid read.

 

I have looked at the logic in the function NITFReadImageLine and it
seems to be flawed in that it mallocs an area which seems to be a
function of the number of requested columns, but then copies imagery
into the buffer using a for-loop based on the block size.  Moreover, the
nLineSize computed for the malloc was not big enough for the requested
area anyway.

 

The problem is only really evident in colour images for which reads are
requested that are smaller than the blocksize in the file.  

 

Whilst I cannot be certain that my replacement logic will suffice for
all NITF configs, I certainly think the memory management in this
function AND the corresponding NITFWriteImageLine should be reviewed?
My changes certainly get rid of my read-errors and crashes (find #####
in the attached code snippet).

 

Opinions anyone?

Gary