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)