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

Claes Redestad claes.redestad at oracle.com
Thu Jan 19 23:04:28 UTC 2017

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.



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