On Wed, 28 Oct 2020 09:19:12 -0400 jma...@redhat.com wrote:
> From: Jon Maloy <jma...@redhat.com>
> 
> TIPC reserves 64 service types for current and future internal use.
> Therefore, the bind() function is meant to block regular user sockets
> from being bound to these values, while it should let through such
> bindings from internal users.
> 
> However, since we at the design moment saw no way to distinguish
> between regular and internal users the filter function ended up
> with allowing all bindings of the reserved types which were really
> in use ([0,1]), and block all the rest ([2,63]).
> 
> This is risky, since a regular user may bind to the service type
> representing the topology server (TIPC_TOP_SRV == 1) or the one used
> for indicating neighboring node status (TIPC_CFG_SRV == 0), and wreak
> havoc for users of those services, i.e., most users.
> 
> The reality is however that TIPC_CFG_SRV never is bound through the
> bind() function, since it doesn't represent a regular socket, and
> TIPC_TOP_SRV can also be made to bypass the checks in tipc_bind()
> by introducing a different entry function, tipc_sk_bind().
> 
> It should be noted that although this is a change of the API semantics,
> there is no risk we will break any currently working applications by
> doing this. Any application trying to bind to the values in question
> would be badly broken from the outset, so there is no chance we would
> find any such applications in real-world production systems.

You say above that it would wreak havoc for most users, not all :)

I'd be more comfortable applying this to net-next, does that work for
you? 

Also perhaps we could add a pr_warn_once() if an application tried
using the reserved values, to help identify this change right away.

> Acked-by: Yung Xue <ying....@windriver.com>
> Signed-off-by: Jon Maloy <jma...@redhat.com>

Reply via email to