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

[Andreas Schneider]

On Wednesday 17 February 2016 18:20:20 Richard Sharpe wrote:
> 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.

Can we move the discussion to the Red Hat Bugzilla? I've opened

https://bugzilla.redhat.com/show_bug.cgi?id=1309730

for the issue. This sounds really serious ...

Thanks,


	-- andreas

-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org