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>