You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Charles Matthew Chen (JIRA)" <ji...@apache.org> on 2010/09/09 20:16:33 UTC
[jira] Commented: (SANSELAN-17) integer overflow unhandled
[ https://issues.apache.org/jira/browse/SANSELAN-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907708#action_12907708 ]
Charles Matthew Chen commented on SANSELAN-17:
----------------------------------------------
I've committed a patch to address the issue Greg Squires's identified.
http://svn.apache.org/viewcvs?view=rev&rev=995526
Brien Voorhees' issue looks similar but unrelated, so I'm leaving this issue open.
> integer overflow unhandled
> --------------------------
>
> Key: SANSELAN-17
> URL: https://issues.apache.org/jira/browse/SANSELAN-17
> 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 ByteSourceArray.java due to a negative byte[] allocation size. The length argument has been found to wrap when called from IccProfileParser.java.
> 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.