Reject out-of-range indices in pack200 BandSet.getReferences

[kali834x]

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]

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

[kali834x]

The catch is that decodeBandInt (both the scalar and the int[] counts overload) is the shared decoder for every band, not just reference bands, so it has no idea the values are pool indices or which pool they'll index into. There's no bound in scope there to check against, and signed codecs like DELTA5 legitimately produce values in other bands that would fail such a check. The earliest point the bound exists is where the ints meet the reference array, and at each affected call site that's the line right after decodeBandInt (ClassBands L981/982, CpBands L493-495, IcBands L162/163), so nothing consumes unchecked values in between. It's also the same spot parseReferences and parseCPIntReferences/parseCPLongReferences already guard. If you'd rather fail inside decodeBandInt I could add a variant that takes the pool size as an upper bound, but that looked more invasive for the same effect.

[kali834x]

decodeBandInt is shared by all the band reads (counts, flags, signed deltas), so it doesn't know which pool, if any, the decoded values will index into, and most of its callers have no bound to check against. The earliest point where the indices and the pool size are both in hand is getReferences, right after the decode, which is where parseReferences already does the same check. These call sites can't just switch to parseReferences because they keep the raw ints around (getCpDescriptorNameInts and friends). Happy to add a bounded overload for the reference bands instead if you'd prefer failing inside the decode.

[garydgregory]

@kali834x Thanks for the analysis, I'll review again.