Re: nl80211: SET_WIPHY_NETNS does not check caller's CAP_NET_ADMIN over the target netns

[Johannes Berg <johannes@sipsolutions.net>]

Hi,

On Sun, 2026-05-03 at 06:55 +0000, Xie Maoyi wrote:
> Hi Johannes,
> 
> I think I have found two related namespace handling gaps in nl80211 on v7.0 mainline. I would appreciate your view on whether they are bugs and whether they are worth fixing. The second one is much narrower than the first.
> 
> Bug A: NL80211_CMD_SET_WIPHY_NETNS does not check the target netns.

I guess that's more a question of convention than anything else?

But I guess we should follow the netdev convention:

> By comparison, net/core/rtnetlink.c::rtnl_get_net_ns_capable() spells out the convention:
> 
>     /* For now, the caller is required to have CAP_NET_ADMIN in
>      * the user namespace owning the target net ns. */
>     if (!sk_ns_capable(sk, net->user_ns, CAP_NET_ADMIN))
>         return ERR_PTR(-EACCES);

which (also?) requires access in the target netns.

> Bug B: nl80211_prepare_wdev_dump() continuation does not re-check netns.
> 
> The first dumpit invocation validates the wdev against the caller via __cfg80211_wdev_from_attrs(..., sock_net(cb->skb->sk), ...). Subsequent invocations look up the wiphy by global index via wiphy_idx_to_wiphy(). They do not re-check sock_net(cb->skb->sk) against the wiphy's current netns.
> 
> Other dump paths in the same file do this check on every iteration. See nl80211_dump_wiphy() at line 3437 and the parallel scheduled scan dump at line 4420.
> 
> If a wiphy moves between dumpit invocations of NL80211_CMD_GET_SCAN via NL80211_CMD_SET_WIPHY_NETNS, the dump silently keeps copying BSS list contents from the wiphy's new netns into the caller's netns. On its own this race needs a separate caller to migrate the wiphy mid-dump. With bug A, the attacker can arrange the race themselves.

This seems ... inconsequential? After all, moving a wireless device
between namespaces doesn't really change the physical layout of the
machine. Perhaps that'd give someone access to the SSID of some hidden
network but that's not really a secret anyway since it's over the air.

Maybe we should fix it for clarity and convention, but I don't see it's
really an issue?

johannes