public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>,
	Bruce Fields <bfields@fieldses.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [bug report] nfsd: Protect session creation and client confirm using client_lock
Date: Thu, 09 Sep 2021 06:19:00 -0400	[thread overview]
Message-ID: <b63e52660e39cc7688921f85eadf1958ced6a869.camel@kernel.org> (raw)
In-Reply-To: <23A4CB30-F551-472F-9F2F-022C40AE1D70@oracle.com>

On Wed, 2021-09-08 at 21:32 +0000, Chuck Lever III wrote:
> 
> > On Sep 8, 2021, at 5:26 PM, Bruce Fields <bfields@fieldses.org> wrote:
> > 
> > On Tue, Sep 07, 2021 at 03:00:23PM +0000, Chuck Lever III wrote:
> > > We have IPV6_SCOPE_ID_LEN as a maximum size of the scope ID,
> > > and it's not a big value. As long as boundary checking is made
> > > to be sufficient, then a stack residency for the device name
> > > should be safe.
> > 
> > Something like this?  (Or are you making a patch?
> 
> I thought Jeff was going to handle it? More below.
> 

No, sorry... I was just suggesting a potential fix. I'd probably rather
you guys fix it since you're better positioned to test this at the
moment.

> 
> > I'm not even sure how to test.)
> > are
> > --b.
> > 
> > diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
> > index 6e4dbd577a39..d435bffc6199 100644
> > --- a/net/sunrpc/addr.c
> > +++ b/net/sunrpc/addr.c
> > @@ -162,8 +162,10 @@ static int rpc_parse_scope_id(struct net *net, const char *buf,
> > 			      const size_t buflen, const char *delim,
> > 			      struct sockaddr_in6 *sin6)
> > {
> > -	char *p;
> > +	char p[IPV6_SCOPE_ID_LEN + 1];
> > 	size_t len;
> > +	u32 scope_id = 0;
> > +	struct net_device *dev;
> > 
> > 	if ((buf + buflen) == delim)
> > 		return 1;
> > @@ -175,29 +177,23 @@ static int rpc_parse_scope_id(struct net *net, const char *buf,
> > 		return 0;
> > 
> > 	len = (buf + buflen) - delim - 1;
> > -	p = kmemdup_nul(delim + 1, len, GFP_KERNEL);
> > -	if (p) {
> > -		u32 scope_id = 0;
> > -		struct net_device *dev;
> > -
> > -		dev = dev_get_by_name(net, p);
> > -		if (dev != NULL) {
> > -			scope_id = dev->ifindex;
> > -			dev_put(dev);
> > -		} else {
> > -			if (kstrtou32(p, 10, &scope_id) != 0) {
> > -				kfree(p);
> > -				return 0;
> > -			}
> > -		}
> > -
> > -		kfree(p);
> > -
> > -		sin6->sin6_scope_id = scope_id;
> > -		return 1;
> > +	if (len > IPV6_SCOPE_ID_LEN)
> > +		return 0;
> > +
> > +	memcpy(p, delim + 1, len);
> > +	p[len] = 0;
> 
> If I recall correctly, Linus prefers us to use the str*()
> functions instead of raw memcpy() in cases like this.
> 

I hadn't heard that. If you already know the length to be copied, then
strcpy and the like tend to be less efficient since they continually
have to check for null terminators as they walk the source string.

> 
> > +
> > +	dev = dev_get_by_name(net, p);
> > +	if (dev != NULL) {
> > +		scope_id = dev->ifindex;
> > +		dev_put(dev);
> > +	} else {
> > +		if (kstrtou32(p, 10, &scope_id) != 0)
> > +			return 0;
> > 	}
> > 
> > -	return 0;
> > +	sin6->sin6_scope_id = scope_id;
> > +	return 1;
> > }
> > 
> > static size_t rpc_pton6(struct net *net, const char *buf, const size_t buflen,
> 
> --
> Chuck Lever
> 
> 
> 

-- 
Jeff Layton <jlayton@kernel.org>


  reply	other threads:[~2021-09-09 10:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07  8:07 [bug report] nfsd: Protect session creation and client confirm using client_lock Dan Carpenter
2021-09-07 11:00 ` Jeff Layton
2021-09-07 15:00   ` Chuck Lever III
2021-09-08 21:26     ` Bruce Fields
2021-09-08 21:32       ` Chuck Lever III
2021-09-09 10:19         ` Jeff Layton [this message]
2021-09-09 14:31           ` Chuck Lever III
2021-09-09 14:56             ` Jeff Layton
2021-09-14 16:37               ` Bruce Fields
2021-09-14 16:48                 ` Chuck Lever III
2021-09-15 14:03                   ` Chuck Lever III

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=b63e52660e39cc7688921f85eadf1958ced6a869.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox