8358456: ZipFile.getInputStream(ZipEntry) throws unspecified IllegalArgumentException

[jaikiran]

Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8358456?

In Java 24, through https://bugs.openjdk.org/browse/JDK-8341597 we did a change which started using the "compressed size" field value for computing a input buffer size for the InflaterInputStream. The change was reasonable. One part of the change removed a check for <= 0 which would have taken into account invalid/unexpected "compressed size" values:
From #21379

There is a check for size <= 0. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be >= 2. I propose we remove this check.

Without that check, the computed input buffer size can end up being <= 0 which is an invalid value for a buffer size and thus results in an IllegalArgumentException from the InflaterInputStream constructor.

My initial thought was to catch the the IllegalArgumentException and rethrow a ZipException, but thinking about it, this clearly is more an issue with the value that we computed as an input buffer size. So I believe the right thing here is to reintroduce the check that was previously in place and in such cases just default to reasonable sized buffer. That's what the commit in this PR does. Additionally, I renamed that variable to inputBufSize to be clear what this size represents.

A new jtreg test has been introduced which reproduces the issue and verifies the fix. tier testing is currently in progress.

P.S: As a separate task we might want to do a similar change as what was done in JDK-8341597, to the ZipFileSystem code. It currently uses the uncompressed size of the entry to decide the input buffer size.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8358456: ZipFile.getInputStream(ZipEntry) throws unspecified IllegalArgumentException (Bug - P4)

Reviewers

• Lance Andersen (@LanceAndersen - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25606/head:pull/25606
$ git checkout pull/25606

Update a local copy of the PR:
$ git checkout pull/25606
$ git pull https://git.openjdk.org/jdk.git pull/25606/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25606

View PR using the GUI difftool:
$ git pr show -t 25606

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25606.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jpai! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@jaikiran This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8358456: ZipFile.getInputStream(ZipEntry) throws unspecified IllegalArgumentException

Reviewed-by: lancea

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 21 new commits pushed to the master branch:

• d7def20: 8358448: JFR: Incorrect time unit for MethodTiming event
• 4604c86: 8357425: (fs) SecureDirectoryStream setPermissions should use fchmodat
• b6f827e: 8348986: Improve coverage of enhanced exception messages
• ... and 18 more: https://git.openjdk.org/jdk/compare/832c5b06e8f278d70398e07d32d63d094a06967c...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@jaikiran The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (bb85e3d2)

[eirbjo]

Looks reasonable to me. I clearly did not consider invalid input for this case, assuming compressed content would at least have the two-byte deflate header.

A good reminder to always consider invalid input.

[eirbjo]

Would be interesting to know what kind of tooling produced this invalid/surprising compressed size. The JBS issues does not indicate this from what I can tell.

[jaikiran]

Hello Eirik,

Would be interesting to know what kind of tooling produced this invalid/surprising compressed size. The JBS issues does not indicate this from what I can tell.

This was uncovered in tests using ZIP/JAR files created through an internal infrastructure. The tests were validating the exception type being thrown from these APIs.

[LanceAndersen]

Thank you Jai for the changes.

They look good

[jaikiran]

Thank you Eirik and Lance for the reviews. tier1, tier2 and tier3 testing completed successfully with this change.

[jaikiran]

/integrate

[openjdk]

Going to push as commit b5cfd76.
Since your change was applied there have been 43 commits pushed to the master branch:

• 683319f: 8357798: ReverseOrderListView uses Boolean boxes after JDK-8356080
• b918dc8: 8357434: x86: Simplify Interpreter::profile_taken_branch
• f17b2bc: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates
• ... and 40 more: https://git.openjdk.org/jdk/compare/832c5b06e8f278d70398e07d32d63d094a06967c...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jaikiran Pushed as commit b5cfd76.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.