RFR: 8210471: GZIPInputStream constructor could leak an un-end()ed Inflater [v2]

Lance Andersen lancea at openjdk.org
Thu May 30 15:04:03 UTC 2024


On Thu, 30 May 2024 12:32:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8210471?
>> 
>> `java.util.zip.Inflater` when instantiated will hold on the native resources which are freed only when `Inflater.end()` is called. The constructor of `java.util.zip.GZIPInputStream` instantiates an `Inflater` for its internal use. After instantiating the `Inflater`, the `GZIPInputStream` constructor before returning from the constructor, can run into either a `IllegalArgumentException` (because the `size` is `<=0`) or an `IOException` when trying to read a GZIP header from the underlying `InputStream`. In either of these cases, the `Inflater` that the `GZIPInputStream` created internally will end up leaking and the caller has no way to `end()` that `Inflater` or even knowledge of that `Inflater`.
>> 
>> The commit in this PR catches the `IOException` when reading the GZIP header and `end()`s the `Inflater`. Furthermore, to prevent instantiation of an `Inflater`, the `GZIPInputStream` constructor before calling `super(...)` will now check the `InputStream` to be non-null and `size` to be `>0`, both of which were being done by the `super` constructor.
>> 
>> Given the nature of the change, no new test has been added. Existing tests in `test/jdk/java/util/zip` continue to pass and tier1, tier2 and tier3 testing is in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   introduce a basic test for GZIPInputStream

Looks good overall, but I believe we need to address the comment below unless I missed something

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 97:

> 95:      */
> 96:     private static Inflater createInflater(InputStream in, int size) {
> 97:         Objects.requireNonNull(in);

I don't believe we currently indicate at at NPE will be thrown if the InputStream is null so this would require a CSR if we need to document it

-------------

PR Review: https://git.openjdk.org/jdk/pull/19475#pullrequestreview-2088514194
PR Review Comment: https://git.openjdk.org/jdk/pull/19475#discussion_r1620877576


More information about the core-libs-dev mailing list