Bug 11565 - Memory leak of struct gensec_security_ops *
Summary: Memory leak of struct gensec_security_ops *
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.0.26
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-21 08:36 UTC by Lev
Modified: 2015-10-29 08:41 UTC (History)
2 users (show)

See Also:


Attachments
git-am fix for master. (1.07 KB, patch)
2015-10-21 18:22 UTC, Jeremy Allison
no flags Details
git-am fix for 4.3.next, 4.2.next. (1.30 KB, patch)
2015-10-22 18:03 UTC, Jeremy Allison
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lev 2015-10-21 08:36:42 UTC
We have a client host that open/closes connection every few seconds:

[2015/10/21 08:13:43.592693,  1, pid=609] ../source3/smbd/service.c:901(make_connection_snum)
  lmsp05w003 (ipv4:10.144.83.114:59187) connect to service lms_share01_smb initially as user nobody (uid=1000000, gid=1000000) (pid 609)
[2015/10/21 08:13:48.412132,  1, pid=609] ../source3/smbd/service.c:1175(close_cnum)
  lmsp05w003 (ipv4:10.144.83.114:59187) closed connection to service lms_share01_smb
[2015/10/21 08:13:52.675338,  1, pid=609] ../source3/smbd/service.c:901(make_connection_snum)
  lmsp05w003 (ipv4:10.144.83.114:59187) connect to service lms_share01_smb initially as user nobody (uid=1000000, gid=1000000) (pid 609)
[2015/10/21 08:13:53.787347,  1, pid=609] ../source3/smbd/service.c:1175(close_cnum)
  lmsp05w003 (ipv4:10.144.83.114:59187) closed connection to service lms_share01_smb
[2015/10/21 08:13:53.795142,  1, pid=609] ../source3/smbd/service.c:1175(close_cnum)
  lmsp05w003 (ipv4:10.144.83.114:59187) closed connection to service lms_share01_smb
[2015/10/21 08:13:53.802959,  1, pid=609] ../source3/smbd/service.c:1175(close_cnum)
  lmsp05w003 (ipv4:10.144.83.114:59187) closed connection to service lms_share01_smb
[2015/10/21 08:13:53.809172,  1, pid=609] ../source3/smbd/service.c:1175(close_cnum)
  lmsp05w003 (ipv4:10.144.83.114:59187) closed connection to service lms_share01_smb
[2015/10/21 08:13:54.052263,  1, pid=609] ../source3/smbd/service.c:901(make_connection_snum)
  lmsp05w003 (ipv4:10.144.83.114:59187) connect to service lms_share01_smb initially as user nobody (uid=1000000, gid=1000000) (pid 609)
[2015/10/21 08:13:54.180033,  1, pid=609] 

In this scenario smbd memory usage constantly grows, until the service is restarted. talloc_report_full shows thousands of struct gensec_security_ops* under tevent_context:

    struct tevent_context          contains 638779 bytes in 13688 blocks (ref 0) 0x7fc25977d9e0
        struct gensec_security_ops *   contains     32 bytes in   1 blocks (ref 0) 0x7fc26bcc8af0
        struct gensec_security_ops *   contains     32 bytes in   1 blocks (ref 0) 0x7fc268bef420
        struct gensec_security_ops *   contains     32 bytes in   1 blocks (ref 0) 0x7fc26fa32540
        ...

The call stack that allocates these structs is:

run_events_poll ->
  tevent_common_loop_immediate ->
    gensec_update_async_trigger ->
      gensec_update ->
        gensec_spnego_update_wrapper ->
          gensec_spnego_update ->
            gensec_spnego_server_try_fallback ->
              gensec_security_mechs ->
                gensec_use_kerberos_mechs

I guess the problem is in gensec_spnego_update's call to gensec_spnego_server_try_fallback:

gensec_spnego_update()
{
...
    return gensec_spnego_server_try_fallback(gensec_security, spnego_state, out_mem_ctx, ev, in, out);
...
}

gensec_spnego_server_try_fallback is defined as 

static NTSTATUS gensec_spnego_server_try_fallback(struct gensec_security *gensec_security, struct spnego_state *spnego_state, struct tevent_context *ev, TALLOC_CTX *out_mem_ctx, const DATA_BLOB in, DATA_BLOB *out);

I.e. out_mem_ctx and ev are passed in an opposite order! As a result gensec_security_ops* becomes child of tevent_context and is never freed.
Comment 1 Lev 2015-10-21 13:53:27 UTC
According to code I suspect bug relevant also to later samba releases, including 4.3.
Comment 2 Jeremy Allison 2015-10-21 18:22:02 UTC
Created attachment 11520 [details]
git-am fix for master.

Can you confirm the following fixes this for you ?

Jermey.
Comment 3 Lev 2015-10-22 16:29:08 UTC
Thanks, Jeremy. Yes the patch fixes the leak.
-Lev.
Comment 4 Jeremy Allison 2015-10-22 18:03:07 UTC
Created attachment 11530 [details]
git-am fix for 4.3.next, 4.2.next.

Cherry-picked from fix that went into master.
Comment 5 Jeremy Allison 2015-10-22 22:24:42 UTC
Re-assigning to Karolin for inclusion in 4.3.next, 4.2.next.
Comment 6 Karolin Seeger 2015-10-28 09:54:23 UTC
Pushed to autobuild-v4-[3|2]-test.
Comment 7 Karolin Seeger 2015-10-29 08:41:09 UTC
(In reply to Karolin Seeger from comment #6)
Pushed to both branches.
Closing out bug report.

Thanks!