Jiri Kosina <jikos@xxxxxxxxxx> writes: > On Tue, 15 Feb 2022, Johannes Berg wrote: > >> > >> > ieee80211_tx_h_select_key() is performing a series of RCU dereferences, >> > but none of the callers seems to be taking RCU read-side lock; let's >> > acquire the lock in ieee80211_tx_h_select_key() itself. >> > >> but but ... >> >> > ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] >> > rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea] >> >> /** >> * ieee80211_tx_dequeue - dequeue a packet from a software tx queue >> * >> * @hw: pointer as obtained from ieee80211_alloc_hw() >> * @txq: pointer obtained from station or virtual interface, or from >> * ieee80211_next_txq() >> * >> * Returns the skb if successful, %NULL if no frame was available. >> * >> * Note that this must be called in an rcu_read_lock() critical section, >> * which can only be released after the SKB was handled. Some pointers in >> [...] >> >> -> driver bug? > > Right you are, thanks. > > CCing Ping-Ke Shih; find updated fix below. > > > > > From: Jiri Kosina <jkosina@xxxxxxx> > Subject: [PATCH] rtw89: fix RCU usage in rtw89_core_txq_push() > > ieee80211_tx_h_select_key() is performing a series of RCU dereferences, > but rtw89_core_txq_push() is calling it (via ieee80211_tx_dequeue_ni()) > without RCU read-side lock held; fix that. I think we have discussed this before, but patchwork can't handle patches the way you embed them in email discussions: https://patchwork.kernel.org/project/linux-wireless/patch/nycvar.YFH.7.76.2202151700540.11721@xxxxxxxxxxxxx/ Please resubmit. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
