There is a issue in the file Scanner-Core/src/main/java/de/rub/nds/scanner/core/guideline/GuidelineIO.java. Specifically in listXmlFiles() lines 91–105:
} else if ("jar".equals(protocol)) {
JarURLConnection jarConnection = (JarURLConnection) url.openConnection();
try (JarFile jarFile = jarConnection.getJarFile()) { // ← gets shared cached instance
Enumeration<JarEntry> entries = jarFile.entries();
while (entries.hasMoreElements()) {
JarEntry entry = entries.nextElement(); // ← line 97: CRASHES here
When Java opens a JAR file through JarURLConnection, it stores the resulting JarFile object in a static final map inside JarFileFactory, i.e. a single instance shared across the entire JVM process (You can check line 161 in https://raw.githubusercontent.com/frohoff/jdk8u-jdk/master/src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java)
So when two threads both call:
JarURLConnection conn = (JarURLConnection) url.openConnection();
JarFile jarFile = conn.getJarFile();
They get the same JarFile object from that static map, not two independent copies. It is as if both threads hold a reference to the same file handle. This can particularly cause error in TLS-Crawler-Development worker threads, because when multiple crawler worker threads concurrently call GuidelineIO.readGuidelines(), they all receive the same JarFile object from the cache.
To reproduce the error you can run the test testExactZipFileClosedExceptionWithBarrier by creating a file in Scanner-Core/src/test/java/de/rub/nds/scanner/core/guideline/GuidelineIOConcurrencyTest.java with the content in attachment
GuidelineIOConcurrencyTest.java
There is a issue in the file
Scanner-Core/src/main/java/de/rub/nds/scanner/core/guideline/GuidelineIO.java. Specifically in listXmlFiles() lines 91–105:When Java opens a JAR file through
JarURLConnection, it stores the resultingJarFileobject in astatic final mapinsideJarFileFactory, i.e. a single instance shared across the entire JVM process (You can check line 161 inhttps://raw.githubusercontent.com/frohoff/jdk8u-jdk/master/src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java)So when two threads both call:
They get the same JarFile object from that static map, not two independent copies. It is as if both threads hold a reference to the same file handle. This can particularly cause error in
TLS-Crawler-Developmentworker threads, because when multiple crawler worker threads concurrently callGuidelineIO.readGuidelines(), they all receive the sameJarFileobject from the cache.To reproduce the error you can run the test
testExactZipFileClosedExceptionWithBarrierby creating a file inScanner-Core/src/test/java/de/rub/nds/scanner/core/guideline/GuidelineIOConcurrencyTest.javawith the content in attachmentGuidelineIOConcurrencyTest.java