[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150924200510.GE25415@mtj.duckdns.org>
Date: Thu, 24 Sep 2015 16:05:10 -0400
From: Tejun Heo <tj@...nel.org>
To: David Miller <davem@...emloft.net>
Cc: herbert@...dor.apana.org.au, cwang@...pensource.com,
tom@...bertland.com, kafai@...com, kernel-team@...com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
torvalds@...ux-foundation.org, jiri@...nulli.us,
nicolas.dichtel@...nd.com, tgraf@...g.ch, sfeldma@...il.com
Subject: Re: [PATCH v2] netlink: Replace rhash_portid with bound
Hello, David.
On Thu, Sep 24, 2015 at 12:11:42PM -0700, David Miller wrote:
> From: Herbert Xu <herbert@...dor.apana.org.au>
> Date: Tue, 22 Sep 2015 11:38:56 +0800
>
> > The commit 1f770c0a09da855a2b51af6d19de97fb955eca85 ("netlink:
> > Fix autobind race condition that leads to zero port ID") created
> > some new races that can occur due to inconcsistencies between the
> > two port IDs.
...
> I've decided to apply this and queue it up for -stable.
This is mostly correct; however, if there are or can be in-kernel
users which create the client side of netlink socket, it isn't. Let's
say such in-kernel user does kernel_connect() and then query the
assigned port number by kernel_getsockname(). That can just return
zero. Maybe such scenario is not possible for some combination of
reasons but why leak this level of synchronization detail to the users
in the first place? This should be terminated from the site where
such synchronization scheme is implemented. This expands the scope of
correctness verification to all possible users of these functions.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists