All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Wang Hai <wanghaifine@gmail.com>
Cc: edumazet@google.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru,
	yoshfuji@linux-ipv6.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Change judgment len position
Date: Wed, 24 Oct 2018 17:57:39 +0200	[thread overview]
Message-ID: <20181024155739.GA25314@1wt.eu> (raw)
In-Reply-To: <20181024154729.5312-1-wanghaifine@gmail.com>

On Wed, Oct 24, 2018 at 11:47:29PM +0800, Wang Hai wrote:
> To determine whether len is less than zero, it should be put before 
> the function min_t, because the return value of min_t is not likely 
> to be less than zero.

Huh? First, the <0 test is made on "len", not "min_t", so it still
is signed. Second, you're in fact completely removing the test here,
look :

>  	struct net *net = sock_net(sk);
>  	int val, len;
>  
> +	len = min_t(unsigned int, len, sizeof(int));
> +

len is used uninitialized here, so the result is undefined.

>  	if (get_user(len, optlen))
>  		return -EFAULT;

Then it gets overridden by get_user()

> -	len = min_t(unsigned int, len, sizeof(int));
> -

Then its positive values are not bounded anymore since you moved the test.

>  	if (len < 0)
>  		return -EINVAL;

Then only negative values are dropped. So unless I'm missing something
obvious, you're just allowing len to be as large as 2GB-1 based on the
user's fed optlen.

Am I wrong ?

Willy

  reply	other threads:[~2018-10-24 15:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-24 15:47 [PATCH] Change judgment len position Wang Hai
2018-10-24 15:57 ` Willy Tarreau [this message]
2018-10-24 16:23   ` Joe Perches
2018-10-24 16:32     ` Willy Tarreau
2018-10-24 16:54       ` Joe Perches
2018-10-24 17:03         ` Eric Dumazet
2018-10-24 17:18           ` Joe Perches
2018-10-24 20:09           ` Willy Tarreau
2018-10-24 15:59 ` Eric Dumazet
2018-10-24 16:01   ` Willy Tarreau
2018-10-24 17:10 ` David Miller
2018-10-24 18:28   ` Joe Perches
2018-10-24 20:48     ` Willy Tarreau
2018-10-24 23:46       ` Joe Perches
2018-10-24 23:46         ` Joe Perches
2018-10-25  0:02         ` David Miller
2018-10-25  0:02           ` David Miller
2018-10-25  0:23           ` Joe Perches
2018-10-25  0:23             ` Joe Perches
2018-10-25  0:23             ` Joe Perches
2018-10-25  0:50             ` Eric Dumazet
2018-10-25  0:50               ` Eric Dumazet
2018-10-25  1:11         ` Fengguang Wu
2018-10-25  1:16           ` Joe Perches
2018-10-25  2:20             ` Al Viro
2018-10-25  2:41               ` Joe Perches
2018-10-25  3:20                 ` Willy Tarreau
2018-10-25  1:03     ` Al Viro
2018-10-24 17:34 ` kbuild test robot

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=20181024155739.GA25314@1wt.eu \
    --to=w@1wt.eu \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wanghaifine@gmail.com \
    --cc=yoshfuji@linux-ipv6.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 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.