linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Chih-Kang Chang <gary.chang@realtek.com>,
	Ping-Ke Shih <pkshih@realtek.com>,
	Sasha Levin <sashal@kernel.org>,
	linux-wireless@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-6.1] wifi: rtw89: flush TX queue before deleting key
Date: Mon,  8 Dec 2025 19:15:36 -0500	[thread overview]
Message-ID: <20251209001610.611575-44-sashal@kernel.org> (raw)
In-Reply-To: <20251209001610.611575-1-sashal@kernel.org>

From: Chih-Kang Chang <gary.chang@realtek.com>

[ Upstream commit 3a12581fc292997f5ca6dafe3238afd39b77e798 ]

In the wpa_supplicant rekey flow, it sends an EAPOL packet 4/4 through
nl80211_tx_control_port() and triggers wake_tx_queue() in the driver.
Then, it sends nl80211_new_key() to configure a new key in mac80211.
However, in wake_tx_queue(), a workqueue is used to process the TX packet,
which might cause the driver to process the EAPOL packet later than
nl80211_new_key(). This results in the EAPOL packet 4/4 being transmitted
with the new key and IV, causing it to be dropped by the AP. Therefore,
needs to flush TX queue before deleting the old key to ensure that the
EAPOL 4/4 packet is transmitted using the old key.

Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251114060128.35363-2-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## 3. CLASSIFICATION

**Type:** Bug fix - Race condition in WPA rekey flow

**User Impact:** WPA rekeying failures, causing:
- WiFi authentication failures
- Connection drops during normal operation
- Poor user experience on networks that perform rekeying

This is a **functional bug**, not a security vulnerability - it causes
legitimate authentication packets to be dropped.

## 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 1 line added
- **Files touched:** 1 file (mac80211.c)
- **Complexity:** Very low

**Pattern already exists in the driver:**
Looking at `ps.c:65`, the same `flush_work(&rtwdev->txq_work)` pattern
is already used before power mode changes. This fix applies the same
proven pattern to key deletion.

**Risk:** Very low - the fix:
- Uses well-understood kernel API (`flush_work()`)
- Follows existing driver patterns
- Only adds a synchronization point, doesn't change logic

## 5. DEPENDENCY CHECK

- `txq_work` has existed since the rtw89 driver was first introduced
  (commit e3ec7017f6a20 in October 2021, kernel 5.16)
- The `set_key` function with the `DISABLE_KEY` path also exists since
  driver inception
- No dependencies on other commits

## 6. STABILITY INDICATORS

**Pros:**
- Simple, obvious fix using well-established pattern
- Clear understanding of the race condition
- Signed off by Realtek developers who maintain this driver

**Cons:**
- No `Cc: stable@vger.kernel.org` tag
- No `Fixes:` tag
- Relatively new commit (November 2025)
- No Tested-by or Reviewed-by tags

## 7. SUMMARY

| Criteria | Assessment |
|----------|------------|
| Fixes real bug | ✅ Yes - WPA rekey failure causing connection issues |
| Obviously correct | ✅ Yes - follows existing pattern, minimal change |
| Small and contained | ✅ Yes - 1 line |
| No new features | ✅ Yes - pure bug fix |
| Stable tag | ❌ No explicit request from maintainer |
| Fixes tag | ❌ Missing |
| Risk | ✅ Very low |
| Dependencies | ✅ None - uses existing infrastructure |

## CONCLUSION

This commit **should be backported** to stable. Despite the lack of
explicit stable tags, it meets all the technical criteria for stable
inclusion:

1. **Fixes a real, user-visible bug** - WPA rekeying failures cause
   authentication problems
2. **Extremely minimal change** - just one line that adds a
   `flush_work()` call
3. **Uses proven pattern** - identical pattern already exists in `ps.c`
4. **Low risk** - synchronization-only change that cannot break existing
   functionality
5. **No dependencies** - the `txq_work` structure has existed since the
   driver was introduced

The fix ensures EAPOL 4/4 packets are transmitted with the correct key
during WPA rekeying, which is essential for proper WiFi operation. The
change is surgical and follows established patterns in the driver.

**YES**

 drivers/net/wireless/realtek/rtw89/mac80211.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtw89/mac80211.c b/drivers/net/wireless/realtek/rtw89/mac80211.c
index 7b04183a3a5dd..064bae533bceb 100644
--- a/drivers/net/wireless/realtek/rtw89/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw89/mac80211.c
@@ -954,6 +954,7 @@ static int rtw89_ops_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 		}
 		break;
 	case DISABLE_KEY:
+		flush_work(&rtwdev->txq_work);
 		rtw89_hci_flush_queues(rtwdev, BIT(rtwdev->hw->queues) - 1,
 				       false);
 		rtw89_mac_flush_txq(rtwdev, BIT(rtwdev->hw->queues) - 1, false);
-- 
2.51.0


      parent reply	other threads:[~2025-12-09  0:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20251209001610.611575-1-sashal@kernel.org>
2025-12-09  0:14 ` [PATCH AUTOSEL 6.18-6.17] wifi: rtw89: use skb_dequeue() for queued ROC packets to prevent racing Sasha Levin
2025-12-09  0:15 ` [PATCH AUTOSEL 6.18-6.12] wifi: mac80211: reset CRC valid after CSA Sasha Levin
2025-12-09  0:15 ` [PATCH AUTOSEL 6.18-5.10] wifi: mt76: mmio_*_copy fix byte order and alignment Sasha Levin
2025-12-09  0:15 ` [PATCH AUTOSEL 6.18-6.12] wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU Sasha Levin
2025-12-09  0:15 ` [PATCH AUTOSEL 6.18-6.17] wifi: rtw89: rtw8852bu: Added dev id for ASUS AX57 NANO USB Wifi dongle Sasha Levin
2025-12-09  0:15 ` [PATCH AUTOSEL 6.18-6.17] wifi: rtw88: Add BUFFALO WI-U3-866DHP to the USB ID list Sasha Levin
2025-12-09  0:15 ` [PATCH AUTOSEL 6.18-6.1] wifi: rtw89: phy: fix out-of-bounds access in rtw89_phy_read_txpwr_limit() Sasha Levin
2025-12-09  0:15 ` Sasha Levin [this message]

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=20251209001610.611575-44-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=gary.chang@realtek.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=pkshih@realtek.com \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).