commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brien Voorhees (JIRA)" <>
Subject [jira] Commented: (SANSELAN-17) integer overflow unhandled
Date Thu, 09 Sep 2010 20:51:36 GMT


Brien Voorhees commented on SANSELAN-17:

  Thanks for looking into the issue.  I actually did attach the image 
('crash.jpeg') when I posted my comment.  It appears to still be there 
(at the top of the page under "Image Attachments").  Just let me know if 
that doesn't work.

I implemented a quick work around for the issue.  Not sure if it's 
comprehensive enough to be patched in but it's included below just in 
case it's helpful.


Modification to the parseAllBlocks() function in  
Modified area  :

           int blockSize = bis
                      .read4ByteInteger("Image Resource Block missing 
              if (verbose)
                  Debug.debug("blockSize", blockSize + " (0x"
                          + Integer.toHexString(blockSize) + ")");
           if(blockSize > bytes.length) // doesn't catch cases where 
blocksize is invalid but is still less than bytes.length but will at 
least prevent OutOfMemory errors
             throw new ImageReadException("Invalid Block Size : 

              byte[] blockData = bis.readByteArray(blockSize,
                      "Invalid Image Resource Block data", verbose, strict);

> integer overflow unhandled
> --------------------------
>                 Key: SANSELAN-17
>                 URL:
>             Project: Commons Sanselan
>          Issue Type: Bug
>    Affects Versions: 0.94-incubator
>         Environment: win32, 32 bit operating systems
>            Reporter: Greg Squires
>         Attachments: crash.jpeg
>   Original Estimate: 24h
>  Remaining Estimate: 24h
> This function can throw an Exception in due to a negative byte[]
allocation size. The length argument has been found to wrap when called from
> In 64bit machines, issues related to incorrect metadata, or ICC data can lead to incorrect
and excess memory allocations. These large numbers however cause 32bit negative signed values.
> 	public byte[] getBlock(int start, int length) throws IOException
> 	{
> 		if (start + length > bytes.length)
> 			throw new IOException("Could not read block (block start: " + start
> 					+ ", block length: " + length + ", data length: "
> 					+ bytes.length + ").");
> 		byte result[] = new byte[length];
> 		System.arraycopy(bytes, start, result, 0, length);
> 		return result;
> 	}

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message