Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Maoyi Xie <maoyixie.tju@gmail.com>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation
Date: Mon, 04 May 2026 15:02:30 +0200	[thread overview]
Message-ID: <c410f8ac2d91b964b279c3f106dd500da3e7afb2.camel@sipsolutions.net> (raw)
In-Reply-To: <20260504125753.1154601-3-maoyi.xie@ntu.edu.sg> (sfid-20260504_145805_299601_518364A5)

On Mon, 2026-05-04 at 20:57 +0800, Maoyi Xie wrote:
> NL80211_CMD_GET_SCAN is implemented as a multi-call dumpit. The first
> invocation of nl80211_prepare_wdev_dump() validates the requested wdev
> against the caller's netns via __cfg80211_wdev_from_attrs(). Subsequent
> invocations look up the same wiphy by global index via
> wiphy_idx_to_wiphy() and do not re-check that the wiphy is still in
> the caller's netns.
> 
> If the wiphy is moved between dumpit invocations (via
> NL80211_CMD_SET_WIPHY_NETNS), the dump silently continues to copy BSS
> list contents from the wiphy's new netns into the caller's netns
> socket buffer. The other dump paths in nl80211.c (e.g.
> nl80211_dump_wiphy() and the parallel scheduled scan dump) already
> filter by net_eq(wiphy_net(...), sock_net(skb->sk)) on every iteration.
> 
> Add the same filter to the continuation path. If the wiphy's netns no
> longer matches the caller's, return -ENODEV and the netlink dump
> machinery terminates the walk cleanly.
> 
> This is most usefully fixed alongside the SET_WIPHY_NETNS target-cap
> hardening in patch 1/2, which closes the path by which an
> unprivileged-userns caller could trigger this race themselves.
> 
> Reported-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
> ---
>  net/wireless/nl80211.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index db546dd93..61b9e5eb0 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -1276,6 +1276,18 @@ static int nl80211_prepare_wdev_dump(struct netlink_callback *cb,
>  			rtnl_unlock();
>  			return -ENODEV;
>  		}
> +		/*
> +		 * The first invocation validated the wdev's netns against
> +		 * the caller via __cfg80211_wdev_from_attrs(). The wiphy
> +		 * may have moved netns between dumpit invocations (via
> +		 * NL80211_CMD_SET_WIPHY_NETNS), so re-check here. Other
> +		 * dump paths in this file (nl80211_dump_wiphy() and friends)
> +		 * already do this check on every iteration.
> +		 */

The code seems fine, but the comment saying "mirror other things" seems
a bit questionable, more about the reason why to make this change than
the static state of the code. If we think it must be unified between all
the callers, then it should probably have a common check function or so.

johannes

  reply	other threads:[~2026-05-04 13:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 12:57 [PATCH 0/2] wifi: nl80211: tighten netns handling in SET_WIPHY_NETNS and dump continuation Maoyi Xie
2026-05-04 12:57 ` [PATCH 1/2] wifi: nl80211: require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS Maoyi Xie
2026-05-04 12:57 ` [PATCH 2/2] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation Maoyi Xie
2026-05-04 13:02   ` Johannes Berg [this message]
2026-05-04 13:54 ` [PATCH v2 0/2] wifi: nl80211: tighten netns handling in SET_WIPHY_NETNS and dump continuation Maoyi Xie
2026-05-04 13:54   ` [PATCH v2 1/2] wifi: nl80211: require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS Maoyi Xie
2026-05-05 10:00     ` Johannes Berg
2026-05-06  6:27       ` Maoyi Xie
2026-05-04 13:54   ` [PATCH v2 2/2] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation Maoyi Xie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c410f8ac2d91b964b279c3f106dd500da3e7afb2.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=maoyixie.tju@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox