Skip to content

reject out-of-range indices in pack200 BandSet.getReferences#788

Open
kali834x wants to merge 1 commit into
apache:masterfrom
kali834x:bandset-getreferences-index-bounds
Open

reject out-of-range indices in pack200 BandSet.getReferences#788
kali834x wants to merge 1 commit into
apache:masterfrom
kali834x:bandset-getreferences-index-bounds

Conversation

@kali834x

Copy link
Copy Markdown
Contributor

BandSet.getReferences resolves a band of decoded integers into entries of a constant-pool array, and its sibling parseReferences does the same job but rejects an index that falls outside the pool with a Pack200Exception. getReferences never applies that check, so the values flow straight into reference[index]. Those indices come from the archive: CpBands.parseCpDescriptor and parseCpSignature feed the cp_Descr_name, cp_Descr_type and cp_Signature_form bands through it, and ClassBands and IcBands do the same for the class/field/method this-class bands. A crafted archive whose band holds an index at or past the referenced pool size makes reference[index] throw a raw ArrayIndexOutOfBoundsException out of the segment read, which the declared throws Pack200Exception was meant to cover. I noticed it while comparing getReferences against parseReferences and the parseCPIntReferences/parseCPLongReferences resolvers, which already guard the same way. Both getReferences overloads now range-check the index and raise the same Pack200Exception, so a corrupt band surfaces as the normal checked exception; the added BandSetTest case exercises both.

  • Read the contribution guidelines for this project.
  • Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
  • I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
  • Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
  • Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

@garydgregory garydgregory left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @kali834x
Should we fail faster instead in org.apache.commons.compress.harmony.unpack200.BandSet.decodeBandInt(String, InputStream, BHSDCodec, int[])?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants