Julian Chandra Sutadi created ZOOKEEPER-5101:
------------------------------------------------
Summary: 4lw client may not close connection correctly if error
occurs during handshake
Key: ZOOKEEPER-5101
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5101
Project: ZooKeeper
Issue Type: Bug
Reporter: Julian Chandra Sutadi
During our testing of ZooKeeper, we found a bug similar to
[ZOOKEEPER-3296|https://issues.apache.org/jira/browse/ZOOKEEPER-3296].
The root cause of ZOOKEEPER-3296 was that QuorumCnxManager did not explicitly
close the SSLSocket when an error occurred during the TLS handshake.
ZOOKEEPER-3296 fixed this by assigning the socket to the sock variable before
startHandshake(), so that QuorumCnxManager.closeSocket(sock) closes it when
called from the catch block.
A similar issue exists in the current 4lw client. In
FourLetterWordMain.send4LetterWord, the SSLSocket is assigned to sock only
after startHandshake() succeeds. If it throws, sock is still null, so the
finally block does not close the SSLSocket. Its file descriptor stays open
until the object is garbage-collected.
{code:java}
Socket sock = null;
try {
...
SSLSocket sslSock = (SSLSocket) socketFactory.createSocket(); // L159
sslSock.connect(hostaddress, timeout);
sslSock.startHandshake(); // L161
may throw
sock = sslSock; // L162
not reached on failure
...
} finally {
if (sock != null) { // L190
sock == null -> SSLSocket not closed
sock.close();
}
...
}
{code}
The suggested fix would be to assign the SSLSocket to the sock variable before
attempting to connect so that it can be properly closed in the finally block if
error occurs. We will submit the fix proposal soon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
