JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

[Xueming Shen]

Thanks Claes!

webrev has been updated accordingly

http://cr.openjdk.java.net/~sherman/8173072/webrev

On 01/19/2017 03:04 PM, Claes Redestad wrote:
> Looks good to me.
>
> You could simplify a bit and write: int end = locPos + locSZ - 4;
> and use direct comparisons instead of adding 4 in each test.
>
> Thanks!
>
> /Claes
>
> On 2017-01-19 22:39, Xueming Shen wrote:
>> Hi
>>
>> Please review the change for
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8173072
>> webrev: http://cr.openjdk.java.net/~sherman/8173072/webrev
>>
>>
>> As described in the issue, the root cause is that the offending zip/jar
>> file
>> has a "extended timestamp extra field" that does not strictly follow the
>> spec, AND the zipfs implementation does not do a good job to do sanity
>> check on the data size like what the ZipEntry code does when check the
>> timestamps. The change here is to check both the flag and the length,
>> stop reading a/ctime if there is no more data, even the flags field says
>> there are more data.
>>
>> I have run the test manually to verify the change, but decided not to check
>> in a binary zip/jar file (which is not encouraged for jdk repo) for the
>> regression test.
>>
>> Thanks,
>> Sherman