JDK-8258753 : StartTlsResponse.close() hangs due to synchronization issues
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 8u261,11,17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-12-21
  • Updated: 2021-07-30
  • Resolved: 2021-03-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15 JDK 16 JDK 17 JDK 8 Other
11.0.12-oracleFixed 15.0.5Fixed 16.0.2Fixed 17 b16Fixed 8u291Fixed openjdk8u302Fixed
Related Reports
Duplicate :  
JDK-8235973 - javax/net/ssl/SSLSocket/Tls13PacketSize.java failed with java.net.SocketException: An established connection was aborted by the software in your host machine
Duplicate :  
JDK-8251199 - javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails with Exception: Unexpected EOF
Duplicate :  
JDK-8221218 - sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java failed with SSLHandshakeException: Insufficient buffer remaining for AEAD cipher fragment (2).
Comments
Fix request (15u) I'd like to backport it here, too. The patch applies cleanly, tier tests run OK.
30-07-2021
Fix request (8u) I'd like to have this bug fix backported to 8u. The 11u patch applies cleanly once the file paths are converted to the previous scheme. No regressions found in jdk/sun/security/ssl tests category.
22-04-2021
Fix Request (11u) This fixes the race condition in SSL code and keeps codebases in sync (I see 11.0.12-oracle). Patch applies cleanly to 11u, passes tier{1,2} and javax/net/ssl tests.
19-04-2021
Fix Request [16u] Requesting backport of this change to resolve race condition between SSL close and read operation further causing the application to hang. The patch applied cleanly to JDK-16u (only copyright has been updated) and was tested with Mach5 tiers 1, 2 and 3 on Linux, Mac OS, Solaris and Windows.
29-03-2021
Changeset: 41555332 Author: Prajwal Kumaraswamy <pkumaraswamy@openjdk.org> Committer: Xue-Lei Andrew Fan <xuelei@openjdk.org> Date: 2021-03-25 03:35:49 +0000 URL: https://git.openjdk.java.net/jdk/commit/41555332
25-03-2021
Going through the 8u251 and 8u261 code, there seems to be a synchronization issue in 8u261. The 8u251 code has synchronized the read operation with a read object lock and either client/main thread can perform read operation at a time. Once client/main thread reads the close_notify acknowledgment from the server, the connection state will be set to closed. Although the main/client thread gets access to read lock (after client/main threads reads close_notify acknowledgment from server), there is a condition before reading from the socket i.e. only if the connection is not closed then fetch the data from the socket. If the connection is closed, then input stream gets closed and exits gracefully without trying to read from socket hence there is no hang or error. In case of 8u261, we do not have a synchronization for read operation and below are the 2 issues observed. 1. Client/Main thread reads the close_notify acknowledgment from server. Further, Main/Client thread (whichever doesn't read ack from server) tries to read from the socket again and waits until SocketTimeOutException, since input buffer is empty. 2. Client/Main thread tries to read from the socket at the same time but gets "Insufficient buffer" error
19-02-2021