In the ath6kl wireless driver, the function aggr_recv_addba_req_evt() receives a window size parameter (win_sz) from firmware and validates it against AGGR_WIN_SZ_MIN/AGGR_WIN_SZ_MAX. When the value falls outside bounds, the code logs a message and then continues using the untrusted value anyway. This is validation as theater: it detects the problem but provides zero protection.
The consequences are immediate. win_sz feeds directly into TID_WINDOW_SZ() to compute a kzalloc size and populates rxtid->hold_q_sz. An out-of-range value creates a structural mismatch between the queue size the code assumes and the buffer actually allocated. Subsequent operations indexing based on hold_q_sz will compute offsets into memory that hasn't been reserved, turning a malformed firmware message into a controllable kernel memory access.
The patch adds cleanup of any active aggregation session followed by an early return—technically trivial, but it requires understanding what state the invalid win_sz already corrupted. That understanding was missing from the original, and the commit structure suggests the validation was written knowing the bounds but choosing to log rather than enforce.
This pattern—firmware-supplied parameters checked but not enforced—recurs across wireless drivers. The kernel's review process treats hardware interfaces as implicitly trusted, an assumption that made sense when firmware blast radius was considered contained, but creates systematic blindspots. You should audit ath6kl for other firmware inputs that are validated but allow execution to continue, and extend that audit to ath9k, brcmfmac, mt76, and similar drivers. The fix isn't just patching this function; it's reclassifying every firmware parameter as adversarial input that must be rejected, not logged.