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.