netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Marcelo Ricardo Leitner' <marcelo.leitner@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>,
	Neil Horman <nhorman@tuxdriver.com>,
	Christoph Hellwig <hch@lst.de>
Subject: RE: [PATCH net-next] sctp: Pull the user copies out of the individual sockopt functions.
Date: Thu, 21 May 2020 16:09:15 +0000	[thread overview]
Message-ID: <a681d1dc056a412bba24b9b4cde37785@AcuMS.aculab.com> (raw)
In-Reply-To: <20200521153729.GB74252@localhost.localdomain>

From: 'Marcelo Ricardo Leitner'
> Sent: 21 May 2020 16:37
> On Wed, May 20, 2020 at 03:08:13PM +0000, David Laight wrote:
...
> > Only SCTP_SOCKOPT_CONNECTX3 contains an indirect pointer.
> > It is also the only getsockopt() that wants to return a buffer
> > and an error code. It is also definitely abusing getsockopt().
> 
> It should have been a linear buffer. The secondary __user access is
> way worse than having the application to do another allocation. But
> too late..

I think that is SCTP_SOCKOPT_CONNECTX ?

> Other than the comments here, this patch LGTM.

Thanks.

> Assuming a v2 is coming, to appease the buildbot :)

I'd got an definition in sctp.h and an EXPORT() but took them out.
I'll also increase the setsockopt limit.

...
> > +	if (optlen < sizeof (param_buf)) {
> > +		if (copy_from_user(&param_buf, u_optval, optlen))
> > +			return -EFAULT;
> > +		optval = param_buf;
> > +	} else {
> > +		if (optlen > USHRT_MAX)
> > +			optlen = USHRT_MAX;
> 
> There are functions that can work with and expect buffers larger than
> that, such as sctp_setsockopt_auth_key:

I'd assumed the maximums were silly.
But a few more than 64k is enough, the lengths are in bytes.
OTOH 128k is a nice round limit - and plenty AFAICT.

...
> > +	if (len < sizeof (param_buf)) {
> > +		/* Zero first bytes to stop KASAN complaining. */
> > +		param_buf[0] = 0;
> > +		if (copy_from_user(&param_buf, u_optval, len))
> > +			return -EFAULT;
> > +		optval = param_buf;
> > +	} else {
> > +		if (len > USHRT_MAX)
> > +			len = USHRT_MAX;
> 
> This limit is not present today for sctp_getsockopt_local_addrs()
> calls (there may be others).  As is, it will limit it and may mean
> that it can't dump all addresses.  We have discussed this and didn't
> come to a conclusion on what is a safe limit to use here, at least not
> on that time.

It needs some limit. memdup_user() might limit at 32MB.
I couldn't decide is some of the allocators limit it further.
In any case an IPv6 address is what? under 128 bytes.
64k is 512 address, things are going to explode elsewhere first.

I didn't see 'get' requests that did 64k + a bit.

It should be possible to loop using a larger kernel buffer if the
data won't fit.
Doable as a later patch to avoid complications.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  parent reply	other threads:[~2020-05-21 16:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 15:08 [PATCH net-next] sctp: Pull the user copies out of the individual sockopt functions David Laight
2020-05-20 23:33 ` kbuild test robot
2020-05-21  0:17 ` 'Marcelo Ricardo Leitner'
2020-05-21  7:32   ` David Laight
2020-05-21 14:36     ` 'Marcelo Ricardo Leitner'
2020-05-21 15:37 ` 'Marcelo Ricardo Leitner'
2020-05-21 15:39   ` Christoph Hellwig
2020-05-21 15:52     ` David Laight
2020-05-21 16:09   ` David Laight [this message]
2020-05-21 16:45     ` 'Marcelo Ricardo Leitner'

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=a681d1dc056a412bba24b9b4cde37785@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=hch@lst.de \
    --cc=linux-sctp@vger.kernel.org \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).