[asterisk-dev] [Code Review] Fix memory leak of SSL_CTX

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1875/
-----------------------------------------------------------

(Updated April 18, 2012, 2:45 p.m.)


Review request for Asterisk Developers.


Changes
-------

Made Matt's suggested fix.

I created a new function called ast_ssl_teardown() that will free an SSL_CTX if it has been allocated. The only callers of this are the destructor for ast_tcptls_instance and when chan_sip unloads. manager.c and http.c also make use of standalone ast_tcptls_config structures, but those are core and not unloadable. They can have their configuration reloaded, but the changes I made in __ssl_setup() in tcptls.c fix the leak that would occur on reload.


Summary
-------

Based on information-gathering in issue ASTERISK-19278, it appears that Asterisk is misusing OpenSSL in a way that causes a slow memory leak. From combing through main/tcptls.c, it appears that one foul-up Asterisk has is to never free any SSL_CTXs that are created. I have patched __ssl_setup() to properly free the SSL_CTX if either

1) We're about to allocate a new one.
2) Some failure occurs during setup.

While I have no confirmation that this is the same memory leak being observed in ASTERISK-19278, this fix seems necessary anyway. I'm placing this patch on Review Board because my unfamiliarity with OpenSSL leads me to seek confirmation that what I am doing makes sense and will not cause issues.


This addresses bug ASTERISK-19278.
    https://issues.asterisk.org/jira/browse/ASTERISK-19278


Diffs (updated)
-----

  /branches/1.8/channels/chan_sip.c 362427 
  /branches/1.8/include/asterisk/tcptls.h 362427 
  /branches/1.8/main/tcptls.c 362427 

Diff: https://reviewboard.asterisk.org/r/1875/diff


Testing
-------

No testing has been done aside from compilation. I will ask the reporter on ASTERISK-19278 to test to see if the memory leak appears to go away.


Thanks,

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120418/d909dee5/attachment.htm>