selabel_lookup leaks 2048 bytes per call on CentOS 6.7 under Samba?

[Richard Sharpe]

On Mon, Feb 15, 2016 at 2:47 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> Hi folks,
>
> my malloc_hook experiment suggests that selabel_linux on
> selinux-2.0.94-5.8.el6 (for RHEL/CentOS 6.7) is leaking 2048 bytes of
> memory under Samba.
>
> Following is the stack trace:
>
> [2016/02/15 14:12:37.713576,  0] ../source3/smbd/server.c:92(samba_malloc_hook)
>   2048 allocate at 0x7f8bbf2fd930
> [2016/02/15 14:12:37.713724,  0] ../source3/smbd/server.c:85(samba_malloc_hook)
>   malloc size of 2048 requested
> [2016/02/15 14:12:37.714175,  0] ../source3/lib/util.c:901(log_stack_trace)
>   BACKTRACE: 46 stack frames:
>    #0 /usr/lib/libsmbconf.so.0(log_stack_trace+0x1f) [0x7f8bbc22e542]
>    #1 smbd(+0xa16c) [0x7f8bbe84416c]
>    #2 /lib64/libc.so.6(__libc_calloc+0x331) [0x7f8bba78fa51]
>    #3 /lib64/libc.so.6(+0xbe7db) [0x7f8bba7d37db]
>    #4 /lib64/libc.so.6(+0xc91a9) [0x7f8bba7de1a9]
>    #5 /lib64/libc.so.6(regexec+0xc3) [0x7f8bba7de553]
>    #6 /lib64/libselinux.so.1(+0xefc7) [0x7f8baeb60fc7]
>    #7 /lib64/libselinux.so.1(+0xd22a) [0x7f8baeb5f22a]
>    #8 /lib64/libselinux.so.1(selabel_lookup+0xe) [0x7f8baeb5f36e]
>    #9 /lib64/libkrb5support.so.0(+0x3af6) [0x7f8bbe653af6]
>    #10 /lib64/libkrb5support.so.0(krb5int_push_fscreatecon_for+0x8c)
> [0x7f8bbe653dec]
>    #11 /lib64/libkrb5.so.3(+0x78d01) [0x7f8bbe70cd01]
>    #12 /lib64/libkrb5.so.3(+0x78b8e) [0x7f8bbe70cb8e]
>    #13 /lib64/libkrb5.so.3(+0x78ecf) [0x7f8bbe70cecf]
>    #14 /lib64/libkrb5.so.3(krb5_get_server_rcache+0x1a1) [0x7f8bbe709101]
>    #15 /lib64/libkrb5.so.3(+0x6d584) [0x7f8bbe701584]
>    #16 /lib64/libkrb5.so.3(krb5_rd_req_decoded+0x2a) [0x7f8bbe7018ea]
>    #17 /lib64/libkrb5.so.3(krb5_rd_req+0xbd) [0x7f8bbe7008fd]
>    #18 /lib64/libgssapi_krb5.so.2(+0x1b4d5) [0x7f8bb1f6a4d5]
>    #19 /lib64/libgssapi_krb5.so.2(+0x1cc3a) [0x7f8bb1f6bc3a]
>    #20 /lib64/libgssapi_krb5.so.2(+0x1cd89) [0x7f8bb1f6bd89]
>    #21 /lib64/libgssapi_krb5.so.2(gss_accept_sec_context+0x20a) [0x7f8bb1f5e53a]
>    #22 /usr/lib/samba/libgse-samba4.so(+0xd830) [0x7f8bb6f1e830]
>    #23 /usr/lib/samba/libgse-samba4.so(+0xe6be) [0x7f8bb6f1f6be]
>    #24 /usr/lib/libgensec.so.0(gensec_update_ev+0xc8) [0x7f8bb6d0034d]
>    #25 /usr/lib/libgensec.so.0(+0xb650) [0x7f8bb6cee650]
>    #26 /usr/lib/libgensec.so.0(+0xc717) [0x7f8bb6cef717]
>    #27 /usr/lib/libgensec.so.0(+0xdd93) [0x7f8bb6cf0d93]
>    #28 /usr/lib/libgensec.so.0(+0x1d8d4) [0x7f8bb6d008d4]
>    #29 /usr/lib/libtevent.so.0(tevent_common_loop_immediate+0x1f9)
> [0x7f8bbaaae384]
>    #30 /usr/lib/libsmbconf.so.0(run_events_poll+0x57) [0x7f8bbc24fdf5]
>    #31 /usr/lib/libsmbconf.so.0(+0x464a2) [0x7f8bbc2504a2]
>    #32 /usr/lib/libtevent.so.0(_tevent_loop_once+0xfc) [0x7f8bbaaad449]
>    #33 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x25) [0x7f8bbaaad6c1]
>    #34 /usr/lib/libtevent.so.0(_tevent_loop_wait+0x2b) [0x7f8bbaaad78c]
>    #35 /usr/lib/samba/libsmbd-base-samba4.so(smbd_process+0xc49)
> [0x7f8bbdd5244b]
>    #36 smbd(+0xb815) [0x7f8bbe845815]
>    #37 /usr/lib/libsmbconf.so.0(run_events_poll+0x544) [0x7f8bbc2502e2]
>    #38 /usr/lib/libsmbconf.so.0(+0x465b8) [0x7f8bbc2505b8]
>    #39 /usr/lib/libtevent.so.0(_tevent_loop_once+0xfc) [0x7f8bbaaad449]
>    #40 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x25) [0x7f8bbaaad6c1]
>    #41 /usr/lib/libtevent.so.0(_tevent_loop_wait+0x2b) [0x7f8bbaaad78c]
>    #42 smbd(+0xc5a9) [0x7f8bbe8465a9]
>    #43 smbd(main+0x159c) [0x7f8bbe847cf7]
>    #44 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f8bba733d5d]
>    #45 smbd(+0x6029) [0x7f8bbe840029]
> [2016/02/15 14:12:37.716145,  0] ../source3/smbd/server.c:92(samba_malloc_hook)
>   2048 allocate at 0x7f8bbf2ff710
>
> Has anyone seen this?
>
> I checked various versions of SeLinux but cannot find a report of such
> a leak being fixed ....

There is something curious here.

Over a four second period Samba called gss_accept_sec_context 2,553
times. That is more than a little curious.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)