Hey, Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK it is possible for userspace to send us requests with three different properties to identify a target network namespace. This affects at least RTM_{NEW,SET}LINK. Each of them could potentially refer to a different network namespace which is confusing. For legacy reasons the kernel will pick the IFLA_NET_NS_PID property first and then look for the IFLA_NET_NS_FD property but there is no reason to extend this type of behavior to network namespace ids. The regression potential is quite minimal since the rtnetlink requests in question either won't allow IFLA_IF_NETNSID requests before 4.16 is out (RTM_{NEW,SET}LINK) or don't support IFLA_NET_NS_{PID,FD} (RTM_{DEL,GET}LINK) in the first place. But maybe I'm missing a reason for allowing multiple properties in the request.
We obviously cannot prevent users from passing both IFLA_NET_NS_PID and IFLA_NET_NS_FD since we have supported this somehow for a long time. So the check I'm proposing is to only fail when both IFLA_IF_NETNSID, and IFLA_NET_NS_PID or IFLA_NET_NS_FD are passed. Thanks! Christian Christian Brauner (1): rtnetlink: require unique netns identifier net/core/rtnetlink.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) -- 2.14.1