Licensee reported issue.

A crash can occur when multiple threads work with the same ZipFileInputStream
object for a ZipEntry in a ZipFile. We understand that the ZipFile APIs are
not declared to be thread safe, but even so, the VM should not crash under
these circumstances. The situation should be handled gracefully by throwing
an Exception.

The problem happens when one of the threads reaches the end of the stream and
calls close() on it. The ZipFileInputStream.close() method clears up the
native memory held by the jzentry and also sets the field holding the address
of the native jzentry structure to 0.

The majority of the read() and close() methods are conducted while holding a
lock on the ZipFile object. If a thread calls read() on a closed stream, -1
is returned by a check which is at the beginning of read():
 
    if (rem == 0)
        return -1;
 
However, there is a small time window between the above check and obtaining
the lock, during which another thread can close the stream. This is the
sequence of events:
 
1. T1 calls read() and passes check described above
2. T2 calls close() and frees up the jzentry
3. T1 obtains the lock on the ZipFile object, and calls ZipFile.read()
 
Step 3 leads to a crash because the jzentry has been freed. This is the stack
trace (from an hs_err file on Windows):
 
    Stack: [0x04fe0000,0x05030000], sp=0x0502d3b4, free space=308k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    C [zip.dll+0x323d] ZIP_Read+0x8
    C [zip.dll+0x1d22] Java_java_util_zip_ZipFile_read+0x68
    j java.util.zip.ZipFile.read(JJJ[BII)I+0
    j java.util.zip.ZipFile.access$1400(JJJ[BII)I+10
    j java.util.zip.ZipFile$ZipFileInputStream.read([BII)I+66
    j java.util.zip.ZipFile$ZipFileInflaterInputStream.fill()V+32
    j java.util.zip.InflaterInputStream.read([BII)I+100
    j java.util.zip.InflaterInputStream.read()I+11
    j ZipCrashTest.run()V+3
    v ~StubRoutines::call_stub
    V [jvm.dll+0x13f24a] JavaCalls::call_helper+0x16a
    V [jvm.dll+0x202c6e] os::os_exception_wrapper+0x6e
    V [jvm.dll+0x13f415] JavaCalls::call_virtual+0x85
    V [jvm.dll+0x13f477] JavaCalls::call_virtual+0x57
    V [jvm.dll+0xeb6bf] thread_entry+0x5f
    V [jvm.dll+0x16042c] JavaThread::thread_main_inner+0x8c
    V [jvm.dll+0x160e67] JavaThread::run+0xf7
    V [jvm.dll+0x1a4a99] java_start+0x99
    C [msvcr100.dll+0x5c556]
    C [msvcr100.dll+0x5c600]
    C [kernel32.dll+0x1336a]
    C [ntdll.dll+0x39f72]
    C [ntdll.dll+0x39f45]
 
It is also important to note that by design, data can be read from the
ZipFileInputStream even after the ZipFile has been closed.
 
We believe that the the best way to avoid a crash is by adding a (rem == 0)
check just before calling ZipFile.read(), when we already have the lock on
the ZipFile (see diffs below).
 

WORKAROUND
----------
Refrain from sharing ZipFileInputStreams between multiple threads.

SUGGESTED FIX
---------------------------
The suggested fix relative to 7u51 is described below. Note that we don't
have to worry about the array length checks ((len <= 0) and (len > rem))
because these are duplicated in ZIP_Read() in zip_util.c. As an aside, it's
not clear to me why we have the redundant checks in the Java layer.
Performance of this code is crucial for class loading etc., so it might be
worth considering the removal of the duplicate checks from ZipFile.read().

--- ZipFile-old.java 2013-12-14 01:58:06.000000000 +0000
+++ ZipFile-new.java 2014-03-14 13:44:44.388224300 +0000
@-664,9 +664,6 @
         }
 
         public int read(byte b[], int off, int len) throws IOException {
- if (rem == 0) {
- return -1;
- }
             if (len <= 0) {
                 return 0;
             }
@-674,6 +671,9 @
                 len = (int) rem;
             }
             synchronized (ZipFile.this) {
+ if (rem == 0) {
+ return -1;
+ }
                 ensureOpenOrZipException();
 
                 len = ZipFile.read(ZipFile.this.jzfile, jzentry, pos, b,