Re: [RFC] problems with alloc_file_pseudo() use in __nfs42_ssc_open()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux