On Mon, 14 Aug 2023 18:22:27 GMT, Lance Andersen <lan...@openjdk.org> wrote:
>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3108:
>>
>>> 3106: break;
>>> 3107: }
>>> 3108: if (size == ZIP64_MINVAL) {
>>
>> Note that we always increase "pos" only in case of "_MINVAL". If the values
>> of size and csize are correct/valid in the "body" of the zip file and only
>> locoff is negative then we should skip two fields in the extra block and
>> read the third one. Otherwise, we may read some random values and throw an
>> exception.
>
> I am not sure I (quite) understand your question completely..
>
> How ZIpFS::readExtra has navigated these fields has not changed
>
> If you have a tool that creates a zip/jar that demonstrates an issue that
> might need further examination, please provide a test case, the tool that
> created the zip/jar in question and open a new bug.
The 8302483 changed this code to throw an exception, this is why I am looking
into it.
You can compare the code in this file and the same code in the ZipFile in the
checkZip64ExtraFieldValues method or the code in the ZipEntry#setExtra0, where
we do not increase the "off" but instead checks for "off+8" or "off + 16". So
if we need to read only the third field we should read "pos+16" but for the
current implementation we will read it at "pos+0" since the pos was not bumped
by the code for two other fields.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293844319
