[PATCH] Fix smbd crash (valgrind error) if generic memcache evicts share mode entry. BUG: https://bugzilla.samba.org/show_bug.cgi?id=13871
jra at samba.org
Sat Mar 30 23:48:19 UTC 2019
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
> 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:
make, then do:
$ make test TESTS=samba3.base.rw1
and you'll get a reliable smbd crash.
make test TESTS=samba3.base.rw1
and then you'll get the valgrind trace
More information about the samba-technical