commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Damjan Jovanovic (Commented) (JIRA)" <>
Subject [jira] [Commented] (SANSELAN-17) integer overflow unhandled
Date Wed, 22 Feb 2012 04:56:48 GMT


Damjan Jovanovic commented on SANSELAN-17:

EXIF was changed to silently ignore bad tags when not in strict mode - exceptions are only
thrown in strict mode. It seems like a good idea to add this for IPTC as well.

That image has multiple APP13 segments. Even if we break instead of throw when the invalid
block size happens, there is another exception later because Sanselan doesn't handle multiple
APP13 segments. Even if only the first segment is returned there, it has no useful data.

On the other hand, there is some debate ( and as to whether files with multiple APP13
segments are valid, because supposedly the APP13 segments can be joined together in some cases.
Maybe when joined together than now invalid length of 86622 becomes valid?

> integer overflow unhandled
> --------------------------
>                 Key: SANSELAN-17
>                 URL:
>             Project: Commons Sanselan
>          Issue Type: Bug
>          Components: Format: JPEG
>    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.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message