Received-SPF: pass (google.com: domain of linux-wireless+bounces-3976-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <181138f2-77c2-47f5-94d0-28ccd52fb166@quicinc.com>
Date: Fri, 23 Feb 2024 14:14:08 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: linux-wireless <linux-wireless@vger.kernel.org>
Content-Language: en-US
From: Jeff Johnson <quic_jjohnson@quicinc.com>
Subject: What is the lifetime of an instance of struct cfg80211_chan_def::chan
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

I'm concerned about a potential race condition in the ath12k driver, but
need to understand the lifetime of struct cfg80211_chan_def::chan to see
if there is an actual issue.

This is the target of my concern, which at first glance looks benign:
static int ath12k_mac_vif_chan(struct ieee80211_vif *vif,
			       struct cfg80211_chan_def *def)
{
	struct ieee80211_chanctx_conf *conf;

	rcu_read_lock();
	conf = rcu_dereference(vif->bss_conf.chanctx_conf);
	*def = conf->def;
	rcu_read_unlock();

	return 0;
}
Note: I've omitted some error code that isn't important to this discussion.

This code starts a read side critical section, gets the config from the
BSS configuration, makes a copy of the conf->def and then exits the read
side critical section. What could go wrong? Well what is this conf->def
that is being copied?
struct ieee80211_bss_conf {
	struct ieee80211_chanctx_conf __rcu *chanctx_conf;

struct ieee80211_chanctx_conf {
	struct cfg80211_chan_def def;

struct cfg80211_chan_def {
	struct ieee80211_channel *chan;
	enum nl80211_chan_width width;
	u32 center_freq1;
	u32 center_freq2;
	struct ieee80211_edmg edmg;
	u16 freq1_offset;
};

Note well the following:
	struct ieee80211_channel *chan;

This is a pointer to some memory. During the time we are in the read
side critical section we are guaranteed that, if this pointer is not
NULL, the memory backing this pointer is valid. But as soon as we exit
the read side critical section there is no guarantee, at least not one
enforced by RCU, that a writer might update, or even free, the memory
referenced by chan.

So I'm trying to determine what else, if anything, protects the lifetime
of this pointer, and I'm getting lost in the mac80211 code, so any hints
would be appreciated.

/jeff