linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key()
@ 2022-02-15 15:47 Jiri Kosina
  2022-02-15 15:50 ` Johannes Berg
  2022-02-15 21:06 ` [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key() kernel test robot
  0 siblings, 2 replies; 6+ messages in thread
From: Jiri Kosina @ 2022-02-15 15:47 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linux-kernel

From: Jiri Kosina <jkosina@suse.cz>

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.

Spotted with rtw89 driver.

This fixes the splat below.

 =============================
 WARNING: suspicious RCU usage
 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G            E
 -----------------------------
 net/mac80211/tx.c:593 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 2 locks held by kworker/u33:0/184:
  #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660
  #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660

 stack backtrace:
 CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G            E     5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13
 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021
 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core]
 Call Trace:
  <TASK>
  dump_stack_lvl+0x58/0x71
  ieee80211_tx_h_select_key+0x2c0/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea]
  process_one_work+0x2d8/0x660
  worker_thread+0x39/0x3e0
  ? process_one_work+0x660/0x660
  kthread+0xe5/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  </TASK>

 =============================
 WARNING: suspicious RCU usage
 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G            E
 -----------------------------
 net/mac80211/tx.c:607 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 2 locks held by kworker/u33:0/184:
  #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660
  #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660

 stack backtrace:
 CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G            E     5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13
 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021
 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core]
 Call Trace:
  <TASK>
  dump_stack_lvl+0x58/0x71
  ieee80211_tx_h_select_key+0x464/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea]
  process_one_work+0x2d8/0x660
  worker_thread+0x39/0x3e0
  ? process_one_work+0x660/0x660
  kthread+0xe5/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  </TASK>

Fixes: a0761a301746e ("mac80211: drop data frames without key on encrypted links")
Fixes: 46f6b06050b73 ("mac80211: Encrypt "Group addressed privacy" action frames")
Fixes: 3cfcf6ac6d69d ("mac80211: 802.11w - Use BIP (AES-128-CMAC)")
Fixes: f7e0104c1a4e7 ("mac80211: support separate default keys")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---

Unless I am missing something, this seems to have been buggy for over a 
decade ... ?

 net/mac80211/tx.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 6d054fed062f..50b33ef70627 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -580,6 +580,7 @@ ieee80211_tx_h_check_control_port_protocol(struct ieee80211_tx_data *tx)
 static ieee80211_tx_result debug_noinline
 ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
 {
+	int ret;
 	struct ieee80211_key *key;
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
 	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
@@ -589,6 +590,8 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
 		return TX_CONTINUE;
 	}
 
+	rcu_read_lock();
+
 	if (tx->sta &&
 	    (key = rcu_dereference(tx->sta->ptk[tx->sta->ptk_idx])))
 		tx->key = key;
@@ -645,18 +648,23 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
 		}
 
 		if (unlikely(tx->key && tx->key->flags & KEY_FLAG_TAINTED &&
-			     !ieee80211_is_deauth(hdr->frame_control)))
-			return TX_DROP;
+			     !ieee80211_is_deauth(hdr->frame_control))) {
+			ret = TX_DROP;
+			goto out;
+		}
 
 		if (!skip_hw && tx->key &&
 		    tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)
 			info->control.hw_key = &tx->key->conf;
 	} else if (ieee80211_is_data_present(hdr->frame_control) && tx->sta &&
 		   test_sta_flag(tx->sta, WLAN_STA_USES_ENCRYPTION)) {
-		return TX_DROP;
+		ret = TX_DROP;
+		goto out;
 	}
-
-	return TX_CONTINUE;
+	ret = TX_CONTINUE;
+out:
+	rcu_read_unlock();
+	return ret;
 }
 
 static ieee80211_tx_result debug_noinline

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key()
  2022-02-15 15:47 [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key() Jiri Kosina
@ 2022-02-15 15:50 ` Johannes Berg
  2022-02-15 16:11   ` [PATCH] rtw89: fix RCU usage in rtw89_core_txq_push() (was Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key()) Jiri Kosina
  2022-02-15 21:06 ` [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key() kernel test robot
  1 sibling, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2022-02-15 15:50 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: linux-wireless, linux-kernel

> 
> 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?

johannes

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH] rtw89: fix RCU usage in rtw89_core_txq_push() (was Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key())
  2022-02-15 15:50 ` Johannes Berg
@ 2022-02-15 16:11   ` Jiri Kosina
  2022-02-15 17:27     ` Kalle Valo
  0 siblings, 1 reply; 6+ messages in thread
From: Jiri Kosina @ 2022-02-15 16:11 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linux-kernel, Ping-Ke Shih

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@suse.cz>
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.

This addresses the splat below.

 =============================
 WARNING: suspicious RCU usage
 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G            E
 -----------------------------
 net/mac80211/tx.c:593 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 2 locks held by kworker/u33:0/184:
  #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660
  #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660

 stack backtrace:
 CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G            E     5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13
 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021
 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core]
 Call Trace:
  <TASK>
  dump_stack_lvl+0x58/0x71
  ieee80211_tx_h_select_key+0x2c0/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea]
  process_one_work+0x2d8/0x660
  worker_thread+0x39/0x3e0
  ? process_one_work+0x660/0x660
  kthread+0xe5/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  </TASK>

 =============================
 WARNING: suspicious RCU usage
 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G            E
 -----------------------------
 net/mac80211/tx.c:607 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 2 locks held by kworker/u33:0/184:
  #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660
  #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660

 stack backtrace:
 CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G            E     5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13
 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021
 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core]
 Call Trace:
  <TASK>
  dump_stack_lvl+0x58/0x71
  ieee80211_tx_h_select_key+0x464/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365]
  rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea]
  process_one_work+0x2d8/0x660
  worker_thread+0x39/0x3e0
  ? process_one_work+0x660/0x660
  kthread+0xe5/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  </TASK>

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 drivers/net/wireless/realtek/rtw89/core.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
index a0737eea9f81..9632e7f218dd 100644
--- a/drivers/net/wireless/realtek/rtw89/core.c
+++ b/drivers/net/wireless/realtek/rtw89/core.c
@@ -1509,11 +1509,12 @@ static void rtw89_core_txq_push(struct rtw89_dev *rtwdev,
 	unsigned long i;
 	int ret;
 
+	rcu_read_lock();
 	for (i = 0; i < frame_cnt; i++) {
 		skb = ieee80211_tx_dequeue_ni(rtwdev->hw, txq);
 		if (!skb) {
 			rtw89_debug(rtwdev, RTW89_DBG_TXRX, "dequeue a NULL skb\n");
-			return;
+			goto out;
 		}
 		rtw89_core_txq_check_agg(rtwdev, rtwtxq, skb);
 		ret = rtw89_core_tx_write(rtwdev, vif, sta, skb, NULL);
@@ -1523,6 +1524,8 @@ static void rtw89_core_txq_push(struct rtw89_dev *rtwdev,
 			break;
 		}
 	}
+out:
+	rcu_read_unlock();
 }
 
 static u32 rtw89_check_and_reclaim_tx_resource(struct rtw89_dev *rtwdev, u8 tid)

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] rtw89: fix RCU usage in rtw89_core_txq_push() (was Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key())
  2022-02-15 16:11   ` [PATCH] rtw89: fix RCU usage in rtw89_core_txq_push() (was Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key()) Jiri Kosina
@ 2022-02-15 17:27     ` Kalle Valo
  2022-02-16 15:27       ` Jiri Kosina
  0 siblings, 1 reply; 6+ messages in thread
From: Kalle Valo @ 2022-02-15 17:27 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Johannes Berg, linux-wireless, linux-kernel, Ping-Ke Shih

Jiri Kosina <jikos@kernel.org> 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@suse.cz>
> 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@cbobk.fhfr.pm/

Please resubmit.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key()
  2022-02-15 15:47 [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key() Jiri Kosina
  2022-02-15 15:50 ` Johannes Berg
@ 2022-02-15 21:06 ` kernel test robot
  1 sibling, 0 replies; 6+ messages in thread
From: kernel test robot @ 2022-02-15 21:06 UTC (permalink / raw)
  To: Jiri Kosina, Johannes Berg; +Cc: kbuild-all, linux-wireless, linux-kernel

Hi Jiri,

I love your patch! Perhaps something to improve:

[auto build test WARNING on wireless-next/main]
[also build test WARNING on wireless/main jberg-mac80211-next/master jberg-mac80211/master v5.17-rc4 next-20220215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Jiri-Kosina/mac80211-fix-RCU-usage-in-ieee80211_tx_h_select_key/20220215-234935
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
config: i386-randconfig-s002-20220214 (https://download.01.org/0day-ci/archive/20220216/202202160406.p1c7XduC-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/cdfe17d7fc283e125686bdd9a6bbc6fd60909bd7
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Jiri-Kosina/mac80211-fix-RCU-usage-in-ieee80211_tx_h_select_key/20220215-234935
        git checkout cdfe17d7fc283e125686bdd9a6bbc6fd60909bd7
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash net/mac80211/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
>> net/mac80211/tx.c:652:29: sparse: sparse: incorrect type in assignment (different base types) @@     expected int ret @@     got restricted ieee80211_tx_result [usertype] @@
   net/mac80211/tx.c:652:29: sparse:     expected int ret
   net/mac80211/tx.c:652:29: sparse:     got restricted ieee80211_tx_result [usertype]
   net/mac80211/tx.c:661:21: sparse: sparse: incorrect type in assignment (different base types) @@     expected int ret @@     got restricted ieee80211_tx_result [usertype] @@
   net/mac80211/tx.c:661:21: sparse:     expected int ret
   net/mac80211/tx.c:661:21: sparse:     got restricted ieee80211_tx_result [usertype]
   net/mac80211/tx.c:664:13: sparse: sparse: incorrect type in assignment (different base types) @@     expected int ret @@     got restricted ieee80211_tx_result [usertype] @@
   net/mac80211/tx.c:664:13: sparse:     expected int ret
   net/mac80211/tx.c:664:13: sparse:     got restricted ieee80211_tx_result [usertype]
>> net/mac80211/tx.c:667:16: sparse: sparse: incorrect type in return expression (different base types) @@     expected restricted ieee80211_tx_result @@     got int ret @@
   net/mac80211/tx.c:667:16: sparse:     expected restricted ieee80211_tx_result
   net/mac80211/tx.c:667:16: sparse:     got int ret

vim +652 net/mac80211/tx.c

   579	
   580	static ieee80211_tx_result debug_noinline
   581	ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
   582	{
   583		int ret;
   584		struct ieee80211_key *key;
   585		struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
   586		struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
   587	
   588		if (unlikely(info->flags & IEEE80211_TX_INTFL_DONT_ENCRYPT)) {
   589			tx->key = NULL;
   590			return TX_CONTINUE;
   591		}
   592	
   593		rcu_read_lock();
   594	
   595		if (tx->sta &&
   596		    (key = rcu_dereference(tx->sta->ptk[tx->sta->ptk_idx])))
   597			tx->key = key;
   598		else if (ieee80211_is_group_privacy_action(tx->skb) &&
   599			(key = rcu_dereference(tx->sdata->default_multicast_key)))
   600			tx->key = key;
   601		else if (ieee80211_is_mgmt(hdr->frame_control) &&
   602			 is_multicast_ether_addr(hdr->addr1) &&
   603			 ieee80211_is_robust_mgmt_frame(tx->skb) &&
   604			 (key = rcu_dereference(tx->sdata->default_mgmt_key)))
   605			tx->key = key;
   606		else if (is_multicast_ether_addr(hdr->addr1) &&
   607			 (key = rcu_dereference(tx->sdata->default_multicast_key)))
   608			tx->key = key;
   609		else if (!is_multicast_ether_addr(hdr->addr1) &&
   610			 (key = rcu_dereference(tx->sdata->default_unicast_key)))
   611			tx->key = key;
   612		else
   613			tx->key = NULL;
   614	
   615		if (tx->key) {
   616			bool skip_hw = false;
   617	
   618			/* TODO: add threshold stuff again */
   619	
   620			switch (tx->key->conf.cipher) {
   621			case WLAN_CIPHER_SUITE_WEP40:
   622			case WLAN_CIPHER_SUITE_WEP104:
   623			case WLAN_CIPHER_SUITE_TKIP:
   624				if (!ieee80211_is_data_present(hdr->frame_control))
   625					tx->key = NULL;
   626				break;
   627			case WLAN_CIPHER_SUITE_CCMP:
   628			case WLAN_CIPHER_SUITE_CCMP_256:
   629			case WLAN_CIPHER_SUITE_GCMP:
   630			case WLAN_CIPHER_SUITE_GCMP_256:
   631				if (!ieee80211_is_data_present(hdr->frame_control) &&
   632				    !ieee80211_use_mfp(hdr->frame_control, tx->sta,
   633						       tx->skb) &&
   634				    !ieee80211_is_group_privacy_action(tx->skb))
   635					tx->key = NULL;
   636				else
   637					skip_hw = (tx->key->conf.flags &
   638						   IEEE80211_KEY_FLAG_SW_MGMT_TX) &&
   639						ieee80211_is_mgmt(hdr->frame_control);
   640				break;
   641			case WLAN_CIPHER_SUITE_AES_CMAC:
   642			case WLAN_CIPHER_SUITE_BIP_CMAC_256:
   643			case WLAN_CIPHER_SUITE_BIP_GMAC_128:
   644			case WLAN_CIPHER_SUITE_BIP_GMAC_256:
   645				if (!ieee80211_is_mgmt(hdr->frame_control))
   646					tx->key = NULL;
   647				break;
   648			}
   649	
   650			if (unlikely(tx->key && tx->key->flags & KEY_FLAG_TAINTED &&
   651				     !ieee80211_is_deauth(hdr->frame_control))) {
 > 652				ret = TX_DROP;
   653				goto out;
   654			}
   655	
   656			if (!skip_hw && tx->key &&
   657			    tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)
   658				info->control.hw_key = &tx->key->conf;
   659		} else if (ieee80211_is_data_present(hdr->frame_control) && tx->sta &&
   660			   test_sta_flag(tx->sta, WLAN_STA_USES_ENCRYPTION)) {
   661			ret = TX_DROP;
   662			goto out;
   663		}
   664		ret = TX_CONTINUE;
   665	out:
   666		rcu_read_unlock();
 > 667		return ret;
   668	}
   669	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] rtw89: fix RCU usage in rtw89_core_txq_push() (was Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key())
  2022-02-15 17:27     ` Kalle Valo
@ 2022-02-16 15:27       ` Jiri Kosina
  0 siblings, 0 replies; 6+ messages in thread
From: Jiri Kosina @ 2022-02-16 15:27 UTC (permalink / raw)
  To: Kalle Valo; +Cc: Johannes Berg, linux-wireless, linux-kernel, Ping-Ke Shih

On Tue, 15 Feb 2022, Kalle Valo wrote:

> 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@cbobk.fhfr.pm/
> 
> Please resubmit.

Ok, I've resubmitted in a separate thread

	https://lore.kernel.org/r/nycvar.YFH.7.76.2202152037000.11721@cbobk.fhfr.pm

Thanks,

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-02-16 15:27 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-15 15:47 [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key() Jiri Kosina
2022-02-15 15:50 ` Johannes Berg
2022-02-15 16:11   ` [PATCH] rtw89: fix RCU usage in rtw89_core_txq_push() (was Re: [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key()) Jiri Kosina
2022-02-15 17:27     ` Kalle Valo
2022-02-16 15:27       ` Jiri Kosina
2022-02-15 21:06 ` [PATCH] mac80211: fix RCU usage in ieee80211_tx_h_select_key() kernel test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).