All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.com>
Cc: linux-nfs@vger.kernel.org, Neil Brown <neilb@suse.de>
Subject: Re: [PATCH] nfsd: check for oversized NFSv2/v3 arguments
Date: Thu, 20 Apr 2017 17:30:14 -0400	[thread overview]
Message-ID: <20170420213014.GA6993@fieldses.org> (raw)
In-Reply-To: <20170420161935.GB4782@fieldses.org>

On Thu, Apr 20, 2017 at 12:19:35PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 18, 2017 at 01:13:51PM -0400, J. Bruce Fields wrote:
> > On Tue, Apr 18, 2017 at 10:25:20AM +1000, NeilBrown wrote:
> > >  I can't say that I like this patch at all.
> > > 
> > > The problem is that:
> > > 
> > > 	pages = size / PAGE_SIZE + 1; /* extra page as we hold both request and reply.
> > > 				       * We assume one is at most one page
> > > 				       */
> > > 
> > > this assumption is never verified.
> > > To my mind, the "obvious" way to verify this assumption is that an
> > > attempt to generate a multi-page reply should fail if there was a
> > > multi-page request.
> > 
> > A third option, by the way, which Ari Kauppi argued for, is adding a
> > null check each time we increment rq_next_page, since we seem to arrange
> > for the page array to always be NULL-terminated.
> > 
> > > Failing if there was a little bit of extra noise at the end of the
> > > request seems harsher than necessary, and could result in a regression.
> > 
> > You're worrying there might be a weird old client out there somewhere?
> > I guess it seems like a small enough risk to me.  I'm more worried the
> > extra garbage might violate assumptions elsewhere in the code.
> > 
> > But, this looks good too:
> 
> But, I'm not too happy about putting that NFSv2/v3-specific check in
> common rpc code.  Also, I think this check comes too late for some of
> the damage.
> 
> I may go with some variation on Ari's idea, let me give it a try....

In the read case, I think Ari's approach wouldn't catch the error until
nfsd_direct_splice_actor(), which doesn't actually look capable of
handling errors.  Maybe that should be fixed.  Or maybe read just needs
some more checks.  Ugh.

--b.

> 
> --b.
> 
> > 
> > > We already know how big replies can get, so we can perform a complete
> > > sanity check quite early:
> > > 
> > > diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> > > index a08aeb56b8e4..14f4d425cf8c 100644
> > > --- a/net/sunrpc/svc.c
> > > +++ b/net/sunrpc/svc.c
> > > @@ -1196,6 +1196,12 @@ svc_process_common(struct svc_rqst *rqstp, struct kvec *argv, struct kvec *resv)
> > >  		goto err_bad_proc;
> > >  	rqstp->rq_procinfo = procp;
> > >  
> > > +	if ((procp->pc_xdrressize == 0 ||
> > > +	     procp->pc_xdrressize > XDR_QUADLEN(PAGE_SIZE)) &&
> > > +	    rqstp->rq_arg.len > PAGE_SIZE)
> > > +		/* The assumption about request/reply sizes in svc_init_buffer() is violated! */
> > > +		goto err_garbage;
> > > +
> > >  	/* Syntactic check complete */
> > >  	serv->sv_stats->rpccnt++;
> > >  
> > > 
> > > I haven't tested this at all and haven't even convinced myself that
> > > it covers every case (though I cannot immediately think of any likely
> > > corners).
> > > 
> > > Does it address your test case?
> > 
> > I'll check, it probably does.
> > 
> > We'd need to limit the test to v2/v3.
> > 
> > I'm also not opposed to doing both (or all three).
> > 
> > --b.

  reply	other threads:[~2017-04-20 21:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-14 15:04 [PATCH] nfsd: check for oversized NFSv2/v3 arguments J. Bruce Fields
2017-04-14 15:09 ` J. Bruce Fields
2017-04-18  0:25   ` NeilBrown
2017-04-18 17:13     ` J. Bruce Fields
2017-04-19  0:17       ` NeilBrown
2017-04-19  0:44         ` J. Bruce Fields
2017-04-20  0:57           ` NeilBrown
2017-04-20 15:16             ` J. Bruce Fields
2017-04-20 16:19       ` J. Bruce Fields
2017-04-20 21:30         ` J. Bruce Fields [this message]
2017-04-20 22:11           ` NeilBrown
2017-04-20 22:19             ` J. Bruce Fields
2017-04-21 21:12         ` J. Bruce Fields
2017-04-23 22:21           ` NeilBrown
2017-04-24 14:06             ` J. Bruce Fields
2017-04-24 21:19               ` J. Bruce Fields
2017-04-24 21:20                 ` J. Bruce Fields
2017-04-25  3:15                   ` NeilBrown
2017-04-25 20:40                     ` J. Bruce Fields
2017-04-26  6:31                       ` NeilBrown
2017-04-25  3:00                 ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170420213014.GA6993@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.