SMBD cores in create_volume_objectid

[Jeremy Allison]

On Tue, May 26, 2015 at 03:55:10PM +0530, Shilpa K wrote:
> Hello,
> 
> On a linux system running Samba 4.2, SMBD cored with following foot-prints:
> 
> #0  0x00007f3619e0f41b in push_ucs2_talloc () from
> /usr/local/samba/lib/libsamba-util.so.0
> #1  0x00007f36180e6387 in E_md4hash () from /usr/local/samba/lib/private/
> libcliauth-samba4.so
> #2  0x00007f361995c175 in create_volume_objectid () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #3  0x00007f3619aac612 in vfswrap_fsctl () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #4  0x00007f3619992a90 in smb_vfs_call_fsctl () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #5  0x00007f36199df4db in smb2_ioctl_filesys () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #6  0x00007f36199dea5d in smbd_smb2_ioctl_send () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #7  0x00007f36199ddf45 in smbd_smb2_request_process_ioctl () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #8  0x00007f36199c78d9 in smbd_smb2_request_dispatch () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #9  0x00007f36199cb572 in smbd_smb2_io_handler () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #10 0x00007f36199cb681 in smbd_smb2_connection_handler () from
> /usr/local/samba/lib/private/libsmbd-base-samba4.so
> #11 0x00007f3617a6c5f7 in run_events_poll () from /usr/local/samba/lib/
> libsmbconf.so.0
> #12 0x00007f3617a6c8c4 in s3_event_loop_once () from /usr/local/samba/lib/
> libsmbconf.so.0
> #13 0x00007f36190233df in _tevent_loop_once () from
> /usr/local/samba/lib/private/libtevent.so.0
> #14 0x00007f361902363f in tevent_common_loop_wait () from
> /usr/local/samba/lib/private/libtevent.so.0
> #15 0x00007f361902370a in _tevent_loop_wait () from
> /usr/local/samba/lib/private/libtevent.so.0
> #16 0x00007f36199ae954 in smbd_process () from /usr/local/samba/lib/private/
> libsmbd-base-samba4.so
> #17 0x00007f361a481890 in smbd_accept_connection ()
> #18 0x00007f3617a6c5f7 in run_events_poll () from /usr/local/samba/lib/
> libsmbconf.so.0
> #19 0x00007f3617a6c8c4 in s3_event_loop_once () from /usr/local/samba/lib/
> libsmbconf.so.0
> #20 0x00007f36190233df in _tevent_loop_once () from
> /usr/local/samba/lib/private/libtevent.so.0
> #21 0x00007f361902363f in tevent_common_loop_wait () from
> /usr/local/samba/lib/private/libtevent.so.0
> #22 0x00007f361902370a in _tevent_loop_wait () from
> /usr/local/samba/lib/private/libtevent.so.0
> #23 0x00007f361a4825f3 in smbd_parent_loop ()
> #24 0x00007f361a483d85 in main ()
> 
> This problem is easily reproducible with following steps:
> 1. Map a share from Windows client. Open a word document
> 2. From the same Windows client, using fsmgmt.msc, connect to the Samba
> server and stop sharing the share mapped in step 1.
> 3. write something to the word document opened in step 1. Then save and
> close file.
> 
> The reason for this crash is, when we stop the share from sharing,
> ServicePtrs pointer for that particular service name becomes null and SMBD
> tries refer this NULL entry, leading to SMBD core.

Hmmm. Once the ServicePtrs pointer becomes NULL we should not be
able to refer to it again. Can you point me at the backtrace point
where this occurs ? At that point we should be removing all references
to it, or if there are existing live references we shouldn't be
setting the pointer to NULL until the last reference has gone
away.