On Tue,  6 Feb 2018 14:19:02 +0100, Christian Brauner wrote:
> +/* Verify that rtnetlink requests supporting network namespace ids
> + * do not pass additional properties potentially referring to different
> + * network namespaces.
> + */
> +static int rtnl_ensure_unique_netns(struct nlattr *tb[],
> +                                 struct netlink_ext_ack *extack)
> +{
> +     /* Requests without network namespace ids have been able to specify
> +      * multiple properties referring to different network namespaces so
> +      * don't regress them.
> +      */
> +     if (!tb[IFLA_IF_NETNSID])
> +             return 0;

I agree with Eric that we should enforce this also for the existing
pid/fd attributes.

> +
> +     /* Caller operates on the current network namespace. */
> +     if (!tb[IFLA_NET_NS_PID] && !tb[IFLA_NET_NS_FD])
> +             return 0;
> +
> +     NL_SET_ERR_MSG(extack, "multiple netns identifying attributes 
> specified");
> +     return -EINVAL;

But if we don't reach an agreement on that, this version is the next
best one. No reason to compare the namespaces whether they're the same,
a message with more than one such attribute is just invalid.

> @@ -2649,6 +2675,10 @@ static int rtnl_dellink(struct sk_buff *skb, struct 
> nlmsghdr *nlh,
>       if (err < 0)
>               return err;
>  
> +     err = rtnl_ensure_unique_netns(tb, extack);
> +     if (err < 0)
> +             return err;
> +
>       if (tb[IFLA_IFNAME])
>               nla_strlcpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ);
>  
> @@ -3045,6 +3079,10 @@ static int rtnl_getlink(struct sk_buff *skb, struct 
> nlmsghdr *nlh,
>       if (err < 0)
>               return err;
>  
> +     err = rtnl_ensure_unique_netns(tb, extack);
> +     if (err < 0)
> +             return err;
> +
>       if (tb[IFLA_IF_NETNSID]) {
>               netnsid = nla_get_s32(tb[IFLA_IF_NETNSID]);
>               tgt_net = get_target_net(NETLINK_CB(skb).sk, netnsid);

dellink and getlink support only netnsid, we should just reject a
message with pid or fd set.

 Jiri

Reply via email to