[PATCH] Fix smbd crash (valgrind error) if generic memcache evicts share mode entry. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13871

[Jeremy Allison]

On Sat, Mar 30, 2019 at 05:07:01PM +0100, Ralph Böhme wrote:
> 
> hm, I don't quite get it. :)

It's possible the heirarchy is screwed
up in some other way. This stuff is really
tricky.

> First, doesn't using a memcache without limit mean, the cache will grow without bounds? What happens if a client recursively opens all files of a largish filesystem?
> 
> Second, ownership on share_mode_data is exclsuviley held either by the memcache or by the the_lock. From the valgrind stacks it looks as if a share_mode_data object was being owned by both subsystems at the same time, so when the memcache deleted it while a lck was also referencing the same object, the TALLOC_FREE(lck) at the end of open_file_ntcreate() accesses freed memory.
> 
> I tried to reproduce the problem under valgrind with 
> 
> # valgrind --log-file=valgrind-%p.lod --trace-children=yes bin/smbd
> 
> and then
> 
> $ bin/smbtorture //localhost/test -U slow%x base.rw1
> 
> but couldn't.
> 
> Can you please share the exact steps how to reproduce the isue? Thanks!

Apply the patch from:

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

(this patch).

https://attachments.samba.org/attachment.cgi?id=15021

make, then do:

$ make test TESTS=samba3.base.rw1

and you'll get a reliable smbd crash.

Use:

export SMBD_VALGRIND=valgrind
make test TESTS=samba3.base.rw1

and then you'll get the valgrind trace
shown.