On Fri, Jan 21, 2022 at 10:32:28PM +0000, Chuck Lever III wrote:
> NFS server patches should be sent to me these days.
Thanks, will remember this next time.
> > On Jan 21, 2022, at 1:50 PM, Dan Aloni <dan.aloni@xxxxxxxxxxxx> wrote:
> >
> > Due to change 8cfb9015280d ("NFS: Always provide aligned buffers to the
> > RPC read layers"), a read of 0xfff is aligned up to server rsize of
> > 0x1000.
> >
> > As a result, in a test where the server has a file of size
> > 0x7fffffffffffffff, and the client tries to read from the offset
> > 0x7ffffffffffff000, the read causes loff_t overflow in the server and it
> > returns an NFS code of EINVAL to the client. The client as a result
> > indefinitely retries the request.
>
> An infinite loop in this case is a client bug.
>
> Section 3.3.6 of RFC 1813 permits the NFSv3 READ procedure
> to return NFS3ERR_INVAL. The READ entry in Table 6 of RFC
> 5661 permits the NFSv4 READ operation to return
> NFS4ERR_INVAL.
>
> Was the client side fix for this issue rejected?
Yeah, see Trond's response in
https://lore.kernel.org/linux-nfs/fa9974724216c43f9bdb3fd39555d398fde11e59.camel@xxxxxxxxxxxxxxx/
So it is both a client and server bugs?
> > diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> > index 738d564ca4ce..754f4e9ff4a2 100644
> > --- a/fs/nfsd/vfs.c
> > +++ b/fs/nfsd/vfs.c
> > @@ -1046,6 +1046,10 @@ __be32 nfsd_read(struct svc_rqst *rqstp, struct svc_fh *fhp,
> > __be32 err;
> >
> > trace_nfsd_read_start(rqstp, fhp, offset, *count);
> > +
> > + if (unlikely(offset + *count > NFS_OFFSET_MAX))
> > + *count = NFS_OFFSET_MAX - offset;
>
> Can @offset ever be larger than NFS_OFFSET_MAX?
We have this check in `nfsd4_read`, `(read->rd_offset >= OFFSET_MAX)`.
(should it have been `>` rather?).
Seems it is missing from NFSv3, should add.
> Does this check have any effect on NFSv4 READ operations?
Indeed it doesn't - my expanded testing shows it only fixed for NFSv3.
Will send an updated patch.
--
Dan Aloni
