All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Arjun Roy <arjunroy.kdev@gmail.com>,
	davem@davemloft.net, netdev@vger.kernel.org, arjunroy@google.com,
	edumazet@google.com, soheil@google.com,
	David Ahern <dsahern@gmail.com>
Subject: Re: [net-next v2] tcp: Explicitly mark reserved field in tcp_zerocopy_receive args.
Date: Tue, 9 Feb 2021 08:15:11 +0200	[thread overview]
Message-ID: <20210209061511.GI20265@unreal> (raw)
In-Reply-To: <20210208104143.60a6d730@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Mon, Feb 08, 2021 at 10:41:43AM -0800, Jakub Kicinski wrote:
> On Sun, 7 Feb 2021 10:26:54 +0200 Leon Romanovsky wrote:
> > On Sat, Feb 06, 2021 at 03:28:28PM -0800, Jakub Kicinski wrote:
> > > On Sat,  6 Feb 2021 12:36:48 -0800 Arjun Roy wrote:
> > > > From: Arjun Roy <arjunroy@google.com>
> > > >
> > > > Explicitly define reserved field and require it to be 0-valued.
> > >
> > > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > > > index e1a17c6b473c..c8469c579ed8 100644
> > > > --- a/net/ipv4/tcp.c
> > > > +++ b/net/ipv4/tcp.c
> > > > @@ -4159,6 +4159,8 @@ static int do_tcp_getsockopt(struct sock *sk, int level,
> > > >  		}
> > > >  		if (copy_from_user(&zc, optval, len))
> > > >  			return -EFAULT;
> > > > +		if (zc.reserved)
> > > > +			return -EINVAL;
> > > >  		lock_sock(sk);
> > > >  		err = tcp_zerocopy_receive(sk, &zc, &tss);
> > > >  		release_sock(sk);
> > >
> > > I was expecting we'd also throw in a check_zeroed_user().
> > > Either we can check if the buffer is zeroed all the way,
> > > or we can't and we shouldn't validate reserved either
> > >
> > > 	check_zeroed_user(optval + offsetof(reserved),
> > > 			  len - offsetof(reserved))
> > > ?
> >
> > There is a check that len is not larger than zs and users can't give
> > large buffer.
> >
> > I would say that is pretty safe to write "if (zc.reserved)".
>
> Which check? There's a check which truncates (writes back to user space
> len = min(len, sizeof(zc)). Application can still pass garbage beyond
> sizeof(zc) and syscall may start failing in the future if sizeof(zc)
> changes.

At least in my tree, we have the length check:
  4155                 if (len > sizeof(zc)) {
  4156                         len = sizeof(zc);
  4157                         if (put_user(len, optlen))
  4158                                 return -EFAULT;
  4159                 }


Ad David wrote below, the "if (zc.reserved)" is enough.

We have following options:
1. Old kernel that have sizeof(sz) upto .reserved and old userspace
-> len <= sizeof(sz) - works correctly.
2. Old kernel that have sizeof(sz) upto .reserved and new userspace that
sends larger struct -> "f (len > sizeof(zc))" will return -EFAULT
3. New kernel that have sizeof(sz) beyond reserved and old userspace
-> any new added field to struct sz should be checked and anyway it is the same as item 1.
4. New kernel and new userspace
-> standard flow.

Thanks

  parent reply	other threads:[~2021-02-09  6:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-06 20:36 [net-next v2] tcp: Explicitly mark reserved field in tcp_zerocopy_receive args Arjun Roy
2021-02-06 23:28 ` Jakub Kicinski
2021-02-07  8:26   ` Leon Romanovsky
2021-02-08 18:41     ` Jakub Kicinski
2021-02-09  2:24       ` David Ahern
2021-02-09  2:53         ` Jakub Kicinski
2021-02-09  3:20           ` David Ahern
2021-02-09  6:29             ` Leon Romanovsky
2021-02-09 16:59             ` Jakub Kicinski
2021-02-09 23:46               ` Arjun Roy
2021-02-10  4:35                 ` David Ahern
2021-02-10 19:23                   ` Arjun Roy
2021-02-09  6:15       ` Leon Romanovsky [this message]
2021-02-09 16:59         ` Jakub Kicinski
2021-02-09 19:01           ` Leon Romanovsky
2021-02-07 17:49 ` David Ahern
2021-02-07 17:53   ` David Ahern

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=20210209061511.GI20265@unreal \
    --to=leon@kernel.org \
    --cc=arjunroy.kdev@gmail.com \
    --cc=arjunroy@google.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=soheil@google.com \
    /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.