[sr-dev] [tracker] Comment added: fixes for memory leak in TLS module

sip-router bugtracker at sip-router.org
Tue Dec 10 14:21:01 CET 2013


THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#380 - fixes for memory leak in TLS module
User who did this - Klaus Darilion (klaus3000)

----------
I reviewed the patch and I think it should be fine, at least it should improve the situation much.

There is on thing were I am not sure if this works safe: In tls_server.c:

static int tls_complete_init(struct tcp_connection* c)
{
        tls_domain_t* dom;
        struct tls_extra_data* data = 0;
        tls_domains_cfg_t* cfg;
        enum tls_conn_states state;

        if (LOW_MEM_NEW_CONNECTION_TEST()){
                ERR("tls: ssl bug #1491 workaround: not enough memory for safe"
                                " operation: %lu\n", shm_available());
                goto error2;
        }
             /* Get current TLS configuration and increase reference
              * count immediately. There is no need to lock the structure
              * here, because it does not get deleted immediately. When
              * SER reloads TLS configuration it will put the old configuration
              * on a garbage queue and delete it later, so we know here that
              * the pointer we get from *tls_domains_cfg will be valid for a while,
                  * at least by the time this function finishes
              */

===> Above comment is not valid anymore and should be changed

        lock_get(tls_domains_cfg_lock);
        cfg = *tls_domains_cfg;

===> cfg points now to the current TLS config. But when is the tls_complete_init() function called? If the function is called after the TLS handshake, and during the TLS handshake the TLS config gets reloaded, then it may happen that the TLS handshake used the old TLS config but increases the refcount of the new TLS config. 


----------

More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=380#comment1217

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.



More information about the sr-dev mailing list