[PATCHES BUG 13865] memcache tracking of talloc object sizes - generic smbd crash bug !

[Jeremy Allison]

On Fri, Mar 29, 2019 at 02:10:37PM -0700, Jeremy Allison via samba-technical wrote:
> > Actually this patchset makes:
> > 
> > make test TESTS=samba3.base.rw1
> > 
> > fail repeatedly. Interesting, I'm trying to track
> > down why (wouldn't have thought it had an effect,
> > but it clearly does :-).
> 
> Oh this is interesting. Error is in:
> 
> ==189102== Invalid read of size 8
> ==189102==    at 0x715DF8E: _tc_free_internal (talloc.c:1162)
> ==189102==    by 0x715F341: _tc_free_children_internal (talloc.c:1666)
> ==189102==    by 0x715E1B2: _tc_free_internal (talloc.c:1183)
> ==189102==    by 0x715F341: _tc_free_children_internal (talloc.c:1666)
> ==189102==    by 0x715E1B2: _tc_free_internal (talloc.c:1183)
> ==189102==    by 0x715E428: _talloc_free_internal (talloc.c:1247)
> ==189102==    by 0x715F78E: _talloc_free (talloc.c:1789)
> ==189102==    by 0x5A5CAC7: open_file_ntcreate (open.c:3851)
> ==189102==    by 0x5A6008F: create_file_unixpath (open.c:5298)
> ==189102==    by 0x5A60D55: create_file_default (open.c:5706)
> ==189102==    by 0x5BDE1E5: vfswrap_create_file (vfs_default.c:582)
> ==189102==    by 0x5A6D54B: smb_vfs_call_create_file (vfs.c:1627)
> ==189102==  Address 0x1f9cd460 is 48 bytes inside a block of size 248 free'd
> ==189102==    at 0x4C2CDBB: free (vg_replace_malloc.c:530)
> ==189102==    by 0x715E370: _tc_free_internal (talloc.c:1221)
> ==189102==    by 0x715E428: _talloc_free_internal (talloc.c:1247)
> ==189102==    by 0x715F78E: _talloc_free (talloc.c:1789)
> ==189102==    by 0x569D681: memcache_delete_element (memcache.c:213)
> ==189102==    by 0x569D73E: memcache_trim (memcache.c:228)
> ==189102==    by 0x569DC54: memcache_do_add (memcache.c:334)
> ==189102==    by 0x569DD7D: memcache_add_talloc (memcache.c:357)
> ==189102==    by 0x5B2D1ED: share_mode_memcache_store (share_mode_lock.c:185)
> ==189102==    by 0x5B2DC72: share_mode_data_destructor (share_mode_lock.c:442)
> ==189102==    by 0x715DF81: _tc_free_internal (talloc.c:1157)
> ==189102==    by 0x715F341: _tc_free_children_internal (talloc.c:1666)
> ==189102==  Block was alloc'd at
> ==189102==    at 0x4C2BB8F: malloc (vg_replace_malloc.c:299)
> ==189102==    by 0x715D324: __talloc_with_prefix (talloc.c:782)
> ==189102==    by 0x715D4BE: __talloc (talloc.c:824)
> ==189102==    by 0x715D944: _talloc_named_const (talloc.c:981)
> ==189102==    by 0x7160D9D: _talloc_zero (talloc.c:2422)
> ==189102==    by 0x5B2DCDC: fresh_share_mode_lock (share_mode_lock.c:463)
> ==189102==    by 0x5B2DF31: get_share_mode_lock_internal (share_mode_lock.c:519)
> ==189102==    by 0x5B2E1EE: get_share_mode_lock (share_mode_lock.c:578)
> ==189102==    by 0x5A5BC7E: open_file_ntcreate (open.c:3448)
> ==189102==    by 0x5A6008F: create_file_unixpath (open.c:5298)
> ==189102==    by 0x5A60D55: create_file_default (open.c:5706)
> ==189102==    by 0x5BDE1E5: vfswrap_create_file (vfs_default.c:582)
> 
> which means that we have an outstanding bug w.r.t.
> storing share modes in the memcache - if they get
> evicted bad things happen.

Here is the fix. The share mode memcache needs to be a separate,
max-length = 0 memcache otherwise elements can get evicted
from it.

This is a generic crash bug in smbd that would have been *very* difficult
to track down :-).

I've loged a bug and will propose this patch as a seperate fix once
it's passed a CI run.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=13871

This definitely need back-porting. Could explain
mysterious smbd crashes.

Jeremy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-smbd-Share-modes-should-not-use-the-generic-memca.patch
Type: text/x-diff
Size: 3840 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190329/9b1205af/0001-s3-smbd-Share-modes-should-not-use-the-generic-memca.diff>