[8u] Request for backporting a series of issues affecting core-libs

2019-07-31 Thread chengjingwei
Hi, all

Would someone help to approve the backport of the following issues?

- Issue list:

JDK-8151788

JDK-8026049

JDK-8149469

JDK-8149469

- Details:

JDK-8151788

Reproduced on 8u:[Yes]

Bug: https://bugs.openjdk.java.net/browse/JDK-8151788

Patch is clean:[Yes]

JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3b503af253a4

JDK-8026049

Reproduced on 8u:[Yes]

Bug: https://bugs.openjdk.java.net/browse/JDK-8026049

Patch is clean:[Yes]

JDK9 Changeset:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/662f01f35702

JDK-8151163

Reproduced on 8u:[Yes]

Bug: https://bugs.openjdk.java.net/browse/JDK-8151163

Patch is clean:[Yes]

JDK9 Changeset:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f9dcefa42da3

JDK-8149469

Reproduced on 8u:[Yes]

Bug: https://bugs.openjdk.java.net/browse/JDK-8149469

Patch is clean:[Yes]

JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5e0fd2cdcd55

These issues are decreasing the stability of our applications. They are
always reproducible with jdk built from the

latest jdk8u master repo.



Issue with SSL handshake implementation

2019-07-30 Thread chengjingwei (A)
Hi,



There may be some issue with the SSL handshake implementation.



In sun.security.x509.X500Name.java, there's a static hashmap field named 
*internedOIDs*, used for caching X.500 attributes.

Each time a new oid is encountered, jdk will cache them into the static hashmap.



With a purposely crafted cert on the client side, it's possible to create some 
long oids, and letting the server

save them permanently during SSL handshake, which will eat server memory, and 
cause OOM & DoS in the end.



Is it necessary to make some changes to this?





BTW, The issue was reported by one of our customers, with the following 
stacktrace.

Although they got this on jdk8u212, I believe the same issue exists in jdk11 
too.



```

http-bio-172.24.18.21-443-exec-4

at java.lang.OutOfMemoryError.()V (OutOfMemoryError.java:48)

at java.util.Arrays.copyOf([Ljava/lang/Object;I)[Ljava/lang/Object; 
(Arrays.java:3181)

at java.util.Vector.grow(I)V (Vector.java:269)

at java.util.Vector.ensureCapacityHelper(I)V (Vector.java:249)

at java.util.Vector.addElement(Ljava/lang/Object;)V (Vector.java:623)

at sun.security.util.DerInputStream.readVector(I)[Lsun/security/util/DerValue; 
(DerInputStream.java:425)

at sun.security.util.DerInputStream.getSequence(I)[Lsun/security/util/DerValue; 
(DerInputStream.java:331)

at sun.security.x509.X500Name.parseDER(Lsun/security/util/DerInputStream;)V 
(X500Name.java:793)

at sun.security.x509.X500Name.(Lsun/security/util/DerInputStream;)V 
(X500Name.java:306)

at sun.security.x509.X509CertInfo.parse(Lsun/security/util/DerValue;)V 
(X509CertInfo.java:649)

at sun.security.x509.X509CertInfo.(Lsun/security/util/DerValue;)V 
(X509CertInfo.java:167)

at sun.security.x509.X509CertImpl.parse(Lsun/security/util/DerValue;)V 
(X509CertImpl.java:1804)

at sun.security.x509.X509CertImpl.([B)V (X509CertImpl.java:195)

at 
sun.security.provider.X509Factory.engineGenerateCertificate(Ljava/io/InputStream;)Ljava/security/cert/Certificate;
 (X509Factory.java:102)

at 
java.security.cert.CertificateFactory.generateCertificate(Ljava/io/InputStream;)Ljava/security/cert/Certificate;
 (CertificateFactory.java:339)

at 
sun.security.ssl.HandshakeMessage$CertificateMsg.(Lsun/security/ssl/HandshakeInStream;)V
 (HandshakeMessage.java:455)

at sun.security.ssl.ServerHandshaker.processMessage(BI)V 
(ServerHandshaker.java:230)

at sun.security.ssl.Handshaker.processLoop()V (Handshaker.java:1037)

at sun.security.ssl.Handshaker.process_record(Lsun/security/ssl/InputRecord;Z)V 
(Handshaker.java:965)

at sun.security.ssl.SSLSocketImpl.readRecord(Lsun/security/ssl/InputRecord;Z)V 
(SSLSocketImpl.java:1064)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake()V 
(SSLSocketImpl.java:1367)

at sun.security.ssl.SSLSocketImpl.startHandshake(Z)V (SSLSocketImpl.java:1395)

at sun.security.ssl.SSLSocketImpl.getSession()Ljavax/net/ssl/SSLSession; 
(SSLSocketImpl.java:2288)

at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(Ljava/net/Socket;)V 
(JSSESocketFactory.java:293)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run()V 
(JIoEndpoint.java:343)

at 
java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V
 (ThreadPoolExecutor.java:1149)

at java.util.concurrent.ThreadPoolExecutor$Worker.run()V 
(ThreadPoolExecutor.java:624)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()V 
(TaskThread.java:61)

at java.lang.Thread.run()V (Thread.java:748)

```



[8u-dev] Deadlock involving FileSystems.getDefault and System.loadLibrary

2019-07-12 Thread chengjingwei (A)
Hi there,

We got a bug report from our customers some time ago, the situation was the 
same as described in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html

So we adopted the patch proposed in
https://bugs.openjdk.java.net/browse/JDK-8194653
and
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059811.html

But after then, we've encountered 2 more issues:

1.   Win32 jdk would crash on a win64 environment when running 
AsynchronousFileChannel test in the jck testsuite

2.   Win32 jdk sometimes throw TimeoutException when running 
AysnchronousChannelGroup test in the jck testsuite

We are pretty sure that these issues came up right after we applied this patch. 
As for the  root cause, we are still investigating.
If someone is interested in these newly introduced issues, I'd like to post 
more details about them.