Details
-
Bug
-
Resolution: Fixed
-
P3
-
8
-
b154
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8174623 | 10 | Xueming Shen | P3 | Resolved | Fixed | b01 |
JDK-8314967 | openjdk8u392 | Xin Liu | P3 | Resolved | Fixed | b04 |
Description
zipfs implementation throws ArrayIndexOutOfBoundsException when handles incorrect "extended timestamp extra field". (wlclient.jar)
The offending zip file has a "extended timestamp extra field" that has sz 5 and flag 3. Info-zip spec defines the "flags" bits as
--------------------------------------
The lower three bits of Flags in both headers indicate which time-
stamps are present in the LOCAL extra field:
bit 0 if set, modification time is present
bit 1 if set, access time is present
bit 2 if set, creation time is present
bits 3-7 reserved for additional timestamps; not set
--------------------------------------
which means when the flag is set to 3, it should contains both mtime and crime, with data size as 9 ( 1 byte flag + 4 bytes mtime + 4 bytes atime).
The ZipEntry handles this situation better by checking both flags and the data length as
if ((flag & 0x1) != 0 && (sz0 + 4) <= sz) {
mtime = unixTimeToFileTime(get32S(extra, off + sz0));
sz0 += 4;
}
if ((flag & 0x2) != 0 && (sz0 + 4) <= sz) {
atime = unixTimeToFileTime(get32S(extra, off + sz0));
sz0 += 4;
}
if ((flag & 0x4) != 0 && (sz0 + 4) <= sz) {
ctime = unixTimeToFileTime(get32S(extra, off + sz0));
sz0 += 4;
}
in which it skips trying to blindly read data does not exist.
ZipFileSystem implementation should do the same thing.
The offending zip file has a "extended timestamp extra field" that has sz 5 and flag 3. Info-zip spec defines the "flags" bits as
--------------------------------------
The lower three bits of Flags in both headers indicate which time-
stamps are present in the LOCAL extra field:
bit 0 if set, modification time is present
bit 1 if set, access time is present
bit 2 if set, creation time is present
bits 3-7 reserved for additional timestamps; not set
--------------------------------------
which means when the flag is set to 3, it should contains both mtime and crime, with data size as 9 ( 1 byte flag + 4 bytes mtime + 4 bytes atime).
The ZipEntry handles this situation better by checking both flags and the data length as
if ((flag & 0x1) != 0 && (sz0 + 4) <= sz) {
mtime = unixTimeToFileTime(get32S(extra, off + sz0));
sz0 += 4;
}
if ((flag & 0x2) != 0 && (sz0 + 4) <= sz) {
atime = unixTimeToFileTime(get32S(extra, off + sz0));
sz0 += 4;
}
if ((flag & 0x4) != 0 && (sz0 + 4) <= sz) {
ctime = unixTimeToFileTime(get32S(extra, off + sz0));
sz0 += 4;
}
in which it skips trying to blindly read data does not exist.
ZipFileSystem implementation should do the same thing.
Attachments
Issue Links
- backported by
-
JDK-8174623 zipfs fails to handle incorrect info-zip "extended timestamp extra field"
- Resolved
-
JDK-8314967 zipfs fails to handle incorrect info-zip "extended timestamp extra field"
- Resolved