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

Xueming Shen xueming.shen at oracle.com
Thu Jan 19 23:35:28 UTC 2017

Thanks Claes!

webrev has been updated accordingly


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

More information about the nio-dev mailing list