This CVE exposes a trust boundary failure in the rtw89 wireless driver that goes beyond a simple missing bounds check. The vulnerability stems from the driver using the mac_id field from RX descriptors — a value generated by external firmware — directly as an array index without validation.
The root cause is a mismatch between two specifications: the hardware descriptor format defines mac_id as an 8-bit field (values 0-255), but the driver's internal data structure allocates only 128 entries. The driver implicitly assumed firmware would only generate values below 128, matching RTW89_MAX_MAC_ID_NUM. This assumption was never enforced with a runtime check.
The practical impact is an out-of-bounds read when rtw89_assoc_link_rcu_dereference() is called with a mac_id >= 128. The dereferenced pointer then flows into association and roaming code paths, potentially exposing adjacent kernel memory contents. At CVSS 8.8, this could range from information disclosure (revealing credentials or ASLR offsets) to kernel panics from invalid dereferences.
The patch adds a simple bounds check, which is correct but reactive. What matters structurally is that firmware occupies an ambiguous trust position — it's not user input, but it's external code operating in a privileged domain. The driver assumed rather than verified firmware output stayed within expected bounds. This pattern — descriptor fields used as array indices without validation — has recurred across Realtek wireless driver generations, suggesting the organizational boundary between firmware and driver teams lacks formal contract mechanisms.
For defenders: verify your kernel version includes the fix (the bound check on mac_id before array indexing). If you operate rtw89 hardware, confirm your distribution's kernel is current. The more structural question is whether other rtw89 code paths trust firmware-generated values similarly — audit RX descriptor processing for other fields used as indices or pointers without validation.