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

[Richard Sharpe]

On Wed, Feb 17, 2016 at 4:18 PM, Jeremy Allison <jra at samba.org> wrote:
> On Wed, Feb 17, 2016 at 04:01:22PM -0800, Richard Sharpe wrote:
>> 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 ....
>>
>> It was actually leaking 10-12MB as a result of this.
>>
>> After messing with changing the krb5-libs-1.10.3, I hacked out the
>> guts of the call to krb5int_push_fscreatecon_for above and the problem
>> went away and Samba now has a nice small heap.
>>
>> Of course, that cannot be the long-term solution, but I thought I
>> would let people know.
>
> Wonder if it's worth just fixing this bug for them.
>
> Do you have a pointer to the same source under Ubuntu ? It'd
> be much easier for me to attack it there...

That's a thought.

Let me look around a bit.

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