All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xin Long <lucien.xin@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: network dev <netdev@vger.kernel.org>, davem <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	David Ahern <dsahern@gmail.com>, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH net] udp: fix the len check in udp_lib_getsockopt
Date: Fri, 28 May 2021 21:47:06 -0400	[thread overview]
Message-ID: <CADvbK_dvj2ywH5nQGcsjAWOKb5hdLfoVnjKNmLsstk3R1j7MyA@mail.gmail.com> (raw)
In-Reply-To: <20210528153911.4f67a691@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>

On Fri, May 28, 2021 at 6:39 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 27 May 2021 15:13:32 -0400 Xin Long wrote:
> > On Thu, May 27, 2021 at 3:12 PM Xin Long <lucien.xin@gmail.com> wrote:
> > > Currently, when calling UDP's getsockopt, it only makes sure 'len'
> > > is not less than 0, then copys 'len' bytes back to usespace while
> > > all data is 'int' type there.
> > >
> > > If userspace sets 'len' with a value N (N < sizeof(int)), it will
> > > only copy N bytes of the data to userspace with no error returned,
> > > which doesn't seem right.
>
> I'm not so sure of that. In cases where the value returned may grow
> with newer kernel releases truncating the output to the size of buffer
> user space provided is pretty normal. I think this code is working as
> intended.
Hard to say, I saw this kind of checks from 1da177e4c3f4 ("Linux-2.6.12-rc2"),
the new codes are using 'len < sizeof(x)'. Comparing to growing 'int', other
structures are more likely to grow.

>
> > > Like in Chen Yi's case where N is 0, it
> > > called getsockopt and got an incorrect value but with no error
> > > returned.
> > >
> > > The patch is to fix the len check and make sure it's not less than
> > > sizeof(int). Otherwise, '-EINVAL' is returned, as it does in other
> > > protocols like SCTP/TIPC.
> > >
> > > Reported-by: Chen Yi <yiche@redhat.com>
> > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > ---
> > >  net/ipv4/udp.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > index 15f5504adf5b..90de2ac70ea9 100644
> > > --- a/net/ipv4/udp.c
> > > +++ b/net/ipv4/udp.c
> > > @@ -2762,11 +2762,11 @@ int udp_lib_getsockopt(struct sock *sk, int level, int optname,
> > >         if (get_user(len, optlen))
> > >                 return -EFAULT;
> > >
> > > -       len = min_t(unsigned int, len, sizeof(int));
> > > -
> > > -       if (len < 0)
> > > +       if (len < sizeof(int))
> > >                 return -EINVAL;
> > >
> > > +       len = sizeof(int);
> > > +
> > >         switch (optname) {
> > >         case UDP_CORK:
> > >                 val = up->corkflag;
> >
> > Note I'm not sure if this fix may break any APP, but the current
> > behavior definitely is not correct and doesn't match the man doc
> > of getsockopt, so please review.
>
> Can you quote the part of man getsockopt you're referring to?
The partial byte(or even 0) of the value returned due to passing a wrong
optlen should be considered as an error. "On error, -1 is returned, and
errno is set appropriately.". Success returned in that case only confuses
the user.

  reply	other threads:[~2021-05-29  1:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 19:12 [PATCH net] udp: fix the len check in udp_lib_getsockopt Xin Long
2021-05-27 19:13 ` Xin Long
2021-05-28 22:39   ` Jakub Kicinski
2021-05-29  1:47     ` Xin Long [this message]
2021-05-29  1:57       ` David Ahern
2021-05-29 16:47         ` Xin Long
2021-05-31  1:31           ` David Ahern
2021-05-31  2:02             ` Xin Long
2021-05-31 10:13         ` David Laight

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=CADvbK_dvj2ywH5nQGcsjAWOKb5hdLfoVnjKNmLsstk3R1j7MyA@mail.gmail.com \
    --to=lucien.xin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.