[PATCH AUTOSEL 6.18-6.1] wifi: rtw89: phy: fix out-of-bounds access in rtw89_phy_read_txpwr_limit()

[Sasha Levin <sashal@kernel.org>]

From: Kuan-Chung Chen <damon.chen@realtek.com>

[ Upstream commit 1dd7e743dd37361c8c1ac89355a8da738e2b81fb ]

Coverity reported a potential out-of-bounds access when 'bw' exceeds the
valid range for the specified band. Add a helper `rtw89_bw_is_valid()`
to check bandwidth validity for each band before accessing limit tables.

Addresses-Coverity-ID: 1598844 ("Out-of-bounds access")
Addresses-Coverity-ID: 1598896 ("Out-of-bounds access")

Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251111022452.28093-6-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit for Stable Backport

### 1. COMMIT MESSAGE ANALYSIS

- **Subject:** Clearly indicates a bug fix - "fix out-of-bounds access"
- **Bug Type:** Out-of-bounds array access (memory safety issue)
- **Source:** Coverity static analysis (IDs 1598844, 1598896)
- **No "Cc: stable@vger.kernel.org"** tag present
- **No "Fixes:" tag** pointing to original buggy commit

### 2. CODE CHANGE ANALYSIS

**The Bug:**
The function `rtw89_phy_read_txpwr_limit()` uses the `bw` (bandwidth)
parameter as an array index in expressions like:
```c
da_lmt = (*rule_da_2ghz->lmt)[bw][ntx][rs][bf][regd][ch_idx];
lmt = (*rule_2ghz->lmt)[bw][ntx][rs][bf][regd][ch_idx];
```

Different bands (2G, 5G, 6G) have different valid bandwidth ranges
(`RTW89_2G_BW_NUM`, `RTW89_5G_BW_NUM`, `RTW89_6G_BW_NUM`). If `bw`
exceeds the valid range for the specified band, an out-of-bounds array
read occurs.

**The Fix:**
1. Adds a new helper function `rtw89_phy_validate_txpwr_limit_bw()` that
   validates bandwidth against band-specific limits
2. Adds a validation check at the beginning of
   `rtw89_phy_read_txpwr_limit()` that returns 0 (safe default) if
   validation fails

**Technical Correctness:**
The fix is straightforward - validate input before using it as array
index. This is a defensive programming pattern that prevents OOB access.

### 3. CLASSIFICATION

- **Bug fix:** Yes - fixes memory safety bug (OOB read)
- **Feature addition:** No
- **Security relevant:** Potentially - OOB access can cause crashes,
  kernel panics, or information leaks

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment |
|--------|------------|
| Lines changed | ~20 lines added |
| Files touched | 1 file (phy.c) |
| Complexity | Low - simple validation check |
| Regression risk | Very low - only adds validation, no behavioral
change for valid inputs |
| Subsystem | rtw89 WiFi driver (Realtek 802.11ax) |

The change is **small and surgical**. It only adds bounds checking and
returns a safe default (0) for invalid inputs. Normal operation is
completely unaffected.

### 5. USER IMPACT

- **Affected users:** Users with Realtek rtw89 WiFi hardware
- **Severity if triggered:** Kernel crash/oops or potential information
  leak
- **Trigger conditions:** Invalid `bw` value exceeding band-specific
  limits
- **Real-world likelihood:** Uncertain - could be triggered by malformed
  firmware/hardware responses or bugs elsewhere in the driver

### 6. STABILITY INDICATORS

- Signed-off by Realtek engineers (maintainer-level confidence)
- No explicit tested-by or reviewed-by tags visible
- Has proper patch link for traceability

### 7. DEPENDENCY CHECK

The fix uses existing constants (`RTW89_*_BW_NUM`) that should exist in
any stable kernel with the rtw89 driver. The rtw89 driver was introduced
in kernel 5.16, so this applies to 6.1.y, 6.6.y, and newer stable
branches.

### DECISION RATIONALE

**For backporting:**
- Fixes a genuine memory safety bug (OOB array access)
- Small, self-contained fix with minimal regression risk
- Defensive in nature - only affects invalid input handling
- OOB access bugs can have security implications

**Against backporting:**
- No explicit "Cc: stable" tag from maintainers
- Coverity-found vs user-reported (no evidence of actual crashes in the
  wild)
- No "Fixes:" tag to identify the original buggy commit

**Verdict:**
Despite the lack of explicit stable tags, this is a legitimate memory
safety fix that:
1. Is obviously correct and small
2. Fixes a real bug (OOB access)
3. Has no risk of regression for valid code paths
4. Could prevent crashes or security issues

The fix meets stable kernel criteria: it's a small, self-contained bug
fix that addresses a real memory safety issue without changing normal
behavior. Out-of-bounds access bugs are the type of issues stable trees
should protect against.

**YES**

 drivers/net/wireless/realtek/rtw89/phy.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c
index ba7feadd75828..e8960fbcb72db 100644
--- a/drivers/net/wireless/realtek/rtw89/phy.c
+++ b/drivers/net/wireless/realtek/rtw89/phy.c
@@ -2339,6 +2339,21 @@ static u8 rtw89_channel_to_idx(struct rtw89_dev *rtwdev, u8 band, u8 channel)
 	}
 }
 
+static bool rtw89_phy_validate_txpwr_limit_bw(struct rtw89_dev *rtwdev,
+					      u8 band, u8 bw)
+{
+	switch (band) {
+	case RTW89_BAND_2G:
+		return bw < RTW89_2G_BW_NUM;
+	case RTW89_BAND_5G:
+		return bw < RTW89_5G_BW_NUM;
+	case RTW89_BAND_6G:
+		return bw < RTW89_6G_BW_NUM;
+	default:
+		return false;
+	}
+}
+
 s8 rtw89_phy_read_txpwr_limit(struct rtw89_dev *rtwdev, u8 band,
 			      u8 bw, u8 ntx, u8 rs, u8 bf, u8 ch)
 {
@@ -2363,6 +2378,11 @@ s8 rtw89_phy_read_txpwr_limit(struct rtw89_dev *rtwdev, u8 band,
 	};
 	s8 cstr;
 
+	if (!rtw89_phy_validate_txpwr_limit_bw(rtwdev, band, bw)) {
+		rtw89_warn(rtwdev, "invalid band %u bandwidth %u\n", band, bw);
+		return 0;
+	}
+
 	switch (band) {
 	case RTW89_BAND_2G:
 		if (has_ant_gain)
-- 
2.51.0