Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 18 Aug 2022 01:01:24 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     Olga Kornievskaia <aglo@umich.edu>
Cc:     linux-nfs <linux-nfs@vger.kernel.org>,
        Olga Kornievskaia <kolga@netapp.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] problems with alloc_file_pseudo() use in __nfs42_ssc_open()
Message-ID: <Yv2BVKuzZdMDY2Td@ZenIV>
References: <Yv1jwsHVWI+lguAT@ZenIV>
 <CAN-5tyFvV7QOxyAQXu3UM5swQVB2roDpQ5CBRVc64Epp1gj9hg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAN-5tyFvV7QOxyAQXu3UM5swQVB2roDpQ5CBRVc64Epp1gj9hg@mail.gmail.com>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

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@zeniv.linux.org.uk> 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...