[cifs] semantics of IPC$ shares (was Re: [PATCH] devpts: Fix NULL pointer dereference in dcache_readdir())

[Al Viro]

On Fri, Oct 04, 2019 at 05:02:20PM +0100, Al Viro wrote:

> 	* (possibly) cifs hitting the same on eviction by memory pressure alone
> (no locked inodes anywhere in sight).  Possibly == if cifs IPC$ share happens to
> show up non-empty (e.g. due to server playing silly buggers).
> 	* (possibly) cifs hitting *another* lovely issue - lookup in one subdirectory
> of IPC$ root finding an alias for another subdirectory of said root, triggering
> d_move() of dentry of the latter.  IF the name happens to be long enough to be
> externally allocated and if dcache_readdir() on root is currently copying it to
> userland, Bad Things(tm) will happen.  That one almost certainly depends upon the
> server playing silly buggers and might or might not be possible.  I'm not familiar
> enough with CIFS to tell.

BTW, I would really appreciate somebody familiar with CIFS giving a braindump on
that.  Questions:

1) What's normally (== without malicious/broken server) seen when you mount
an IPC$ share?

2) Does it ever have subdirectories (i.e. can we fail a lookup in its root if it
looks like returning a subdirectory)?

3) If it can be non-empty, is there way to ask the server about its contents?
Short of "look every possible name up", that is...

As it is, the thing is abusing either cifs_lookup() (if it really shouldn't
have any files in it) or dcache_readdir().  Sure, dcache_readdir() can (and
should) pin a dentry while copying the name to userland, but WTF kind of
semantics it is?  "ls will return the things you'd guessed to look up, until
there's enough memory pressure to have them forgotten, which can happen at
any point with no activity on server"?