Possible fd leak in session_client_tls.c

[rakichinni]

Hi @michalvasko,

libnetconf2 version 4.4.2.

Scenario: If the CA cert at the netconf server is not a valid for netconf client. Establishing Netconf session using call-home with TLS ends up not closing fd.

Code snippet: nc_client_tls_session_new() in session_client_tls.c from line 294 to 324.

   sock = -1;
...
    while ((ret = nc_client_tls_handshake_step_wrap(tls_session, sock_tmp)) == 0) {
        usleep(NC_TIMEOUT_STEP);
        if ((timeout > -1) && (nc_timeouttime_cur_diff(&ts_timeout) < 1)) {
            ERR(NULL, "SSL connect timeout.");
            goto fail;
        }
    }

    /* check if handshake was ok */
    if (nc_client_tls_connect_check(ret, tls_session, host) != 1) {
        goto fail;
    }

    *out_tls_cfg = tls_cfg;
    return tls_session;

fail:
//************As the sock is set to -1 above. Flow will never enter inside _if_ block and sock is not closed.
    if (sock > -1) {
        close(sock);
    }

Please let us know if its a known issue.

Thanks.

[michalvasko]

Just before the socket is set to -1, it is assigned into the TLS session. In the fail section, the TLS session is always freed, with any socket if set before. So the current code just makes sure the socket is not closed twice and it should work fine unless you have reproduced an issue.

[rakichinni]

nc_tls_session_destroy_wrap(tls_session) does SSL_free(tls_session) which doesn't close assigned socket. Assigned sock won't be closed unless BIO_CLOSE flag is set. In current impl, BIO_CLOSE flag is not set in session and default is BIO_NOCLOSE.

Yes, we observed fd leak when Netconf server's CA cert validation fails at client. Suspecting above mentioned block might be causing the leak.

[michalvasko]

Yes, you are right, the socket is always closed separately but not in this case, fixed.