On Wed, Aug 17, 2022 at 06:32:15PM -0400, Olga Kornievskaia wrote: > On Wed, Aug 17, 2022 at 6:18 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > My apologies for having missed that back when the SSC > > patchset had been done (and missing the problems after it got > > merged, actually). > > > > 1) if this > > r_ino = nfs_fhget(ss_mnt->mnt_sb, src_fh, fattr); > > in __nfs42_ssc_open() yields a directory inode, we are screwed > > as soon as it's passed to alloc_file_pseudo() - a *lot* of places > > in dcache handling would break if we do that. It's not too > > nice for a regular file from non-cooperating filesystem, but for > > directory ones it's deadly. > > This inode is created to make an appearance of an opened file to do > (an NFS) read, it's never a directory. Er... Where does the fhandle come from? From my reading it's a client-sent data; I don't know what trust model do you assume, but the price of getting multiple dentries over the same directory inode is high. Bogus or compromised client should not be able to cause severe corruption of kernel data structures...
