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

[Ralph Böhme]

> Am 30.03.2019 um 00:04 schrieb Jeremy Allison <jra at samba.org>:
> 
> Official request for review for fix for bug:
> 
> https://bugzilla.samba.org/show_bug.cgi?id=13871
> 
> discovered by Chrisofs memcache code changes.
> 
> Short version, we shouldn't be storing
> share mode entries in the generic memcache
> where they might get evicted whist being
> in use :-(.
> 
> Bug report has the valgrind trace and
> reproducibility info (essentially add
> the patch from bug: 13865 and do
> 
> make test TESTS=samba3.base.rw1
> 
> Passed gitlab-CI.
> 
> Please review and push if happy.

hm, I don't quite get it. :)

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!

-slow