Bug 3458 - winbindd and smbd dump core in certain circumstances
winbindd and smbd dump core in certain circumstances
Product: Samba 3.0
Classification: Unclassified
Component: winbind
x86 FreeBSD
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-01-27 12:09 UTC by Andriy Gapon
Modified: 2006-01-27 12:25 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Gapon 2006-01-27 12:09:00 UTC
winbindd and ocassionally smbd dump core in certain circumstances, for me always on startup and on any access from network.
I believe this is caused by a bug in passdb/secrets.c:secrets_fetch_trust_account_password().
Namely, under some conditions pointer *pass is dereferenced after being cleared with SAFE_FREE.
Here's the corresponding code snippet:
    303         memcpy(ret_pwd, pass->hash, 16);
    304         SAFE_FREE(pass);
    306         if (channel) {
    307                 *channel = get_default_sec_channel();
    308         }
    310         /* Test if machine password has expired and needs to be changed */
    311         if (lp_machine_password_timeout()) {
    312                 if (pass->mod_time > 0 && time(NULL) > (pass->mod_time +
    313                                 lp_machine_password_timeout())) {
    314                         global_machine_password_needs_changing = True;
    315                 }
    316         }

Here's the winbindd stack trace:
#0  secrets_fetch_trust_account_password (domain=0x0, ret_pwd=0xbfbfceb0 "&#9562;;]\200ZyP_8&#1091;<\037>\033&#1070;d&#1061;@\037\b\001", 
    pass_last_set_time=0xbfbfceac, channel=0x0) at passdb/secrets.c:312
312                     if (pass->mod_time > 0 && time(NULL) > (pass->mod_time +
(gdb) bt
#0  secrets_fetch_trust_account_password (domain=0x0, ret_pwd=0xbfbfceb0 "&#9562;;]\200ZyP_8&#1091;<\037>\033&#1070;d&#1061;@\037\b\001", 
    pass_last_set_time=0xbfbfceac, channel=0x0) at passdb/secrets.c:312
#1  0x081a70b6 in must_use_pdc (domain=0x93a80 <Address 0x93a80 out of bounds>) at passdb/secrets.c:837
#2  0x08083ebc in get_dcs (mem_ctx=0x820a1b0, domain=0x8209000, dcs=0xbfbfd064, num_dcs=0xbfbfd068) at nsswitch/winbindd_cm.c:664
#3  0x080840e0 in find_new_dc (mem_ctx=0x820a1b0, domain=0x8209000, dcname=0x8209264 "", addr=0x8209364, fd=0x93a80)
    at nsswitch/winbindd_cm.c:713
#4  0x080849a6 in cm_open_connection (domain=0x8209000, new_conn=0x8209380) at nsswitch/winbindd_cm.c:805
#5  0x08084f0a in init_dc_connection (domain=0x8209000) at nsswitch/winbindd_cm.c:904
#6  0x08084f90 in set_dc_type_and_flags (domain=0x8209000) at nsswitch/winbindd_cm.c:937
#7  0x08076a63 in winbindd_dual_init_connection (domain=0x8209000, state=0xbfbfd240) at nsswitch/winbindd_util.c:471
#8  0x0808aa8f in child_process_request (domain=0x93a80, state=0xbfbfd240) at nsswitch/winbindd_dual.c:389
#9  0x0808b059 in fork_domain_child (child=0x82093cc) at nsswitch/winbindd_dual.c:516
#10 0x0808a60e in schedule_async_request (child=0x82093cc) at nsswitch/winbindd_dual.c:221
#11 0x0808a1ea in async_request (mem_ctx=0x8210f70, child=0x82093cc, request=0x93a80, response=0x93a80, 
    continuation=0x8076720 <init_child_recv>, private_data=0x820ba30) at nsswitch/winbindd_dual.c:132
#12 0x08076538 in init_child_connection (domain=0x8209000, continuation=0x808a8c0 <domain_init_recv>, private_data=0x820b930)
    at nsswitch/winbindd_util.c:371
#13 0x0808a796 in async_domain_request (mem_ctx=0x8210ef0, domain=0x8209000, request=0x821a030, response=0x821a830, 
    continuation=0x8075f10 <trustdom_recv>, private_data_data=0x8210f30) at nsswitch/winbindd_dual.c:279
#14 0x08075efd in add_trusted_domains (domain=0x93a80) at nsswitch/winbindd_util.c:220
#15 0x080762b7 in rescan_trusted_domains () at nsswitch/winbindd_util.c:310
#16 0x0806f361 in process_loop () at nsswitch/winbindd.c:750
#17 0x0806ff1a in main (argc=604800, argv=0x93a80) at nsswitch/winbindd.c:1075

This is when the bug appears to have been introduced:

Moving SAFE_FREE(pass) towards the very end of the function fixes the bug for me.
Comment 1 Jeremy Allison 2006-01-27 12:25:12 UTC
Parfect analysis - thanks. This'll be fixed for 3.0.21b. I really appreciate your help.