Re: [PATCH v2] wifi: ath9k: reject short WMI command responses

[Jeff Johnson]

On 9/17/2026 1:56 AM, Toke Høiland-Jørgensen wrote:
> Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxx> writes:
> 
>> On 8/14/2026 12:58 AM, Pengpeng Hou wrote:
>>> ath9k_wmi_rsp_callback() removes the validated WMI header and copies
>>> the number of bytes expected by the waiting command into its response
>>> buffer. A device response shorter than that expectation can therefore
>>> be read beyond the skb payload.
>>>
>>> Record -EMSGSIZE for a short response, complete the waiter, and return
>>> the stored status from the command path. This also prevents callers from
>>> consuming stale response bytes as a successful reply.
>>>
>>> Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
>>> Assisted-by: Codex:gpt-5
>>> Signed-off-by: Pengpeng Hou <pengpeng@xxxxxxxxxxx>
>>> ---
>>> Changes since v1: https://lore.kernel.org/all/20260704011405.55089-1-pengpeng@xxxxxxxxxxx/
>>> - return a stored response error to the waiting command
>>> - retain acceptance of replies longer than the requested prefix
>>> - recheck callback synchronization under the existing WMI lock
>>>
>>> The WMI callback and waiter synchronization were reviewed statically; no
>>> ath9k firmware fault injection was performed.
>>>
>>>  drivers/net/wireless/ath/ath9k/wmi.c | 17 +++++++++++++++--
>>>  drivers/net/wireless/ath/ath9k/wmi.h |  1 +
>>>  2 files changed, 16 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
>>> index 284e8c13b043..06d9975f9717 100644
>>> --- a/drivers/net/wireless/ath/ath9k/wmi.c
>>> +++ b/drivers/net/wireless/ath/ath9k/wmi.c
>>> @@ -206,8 +206,16 @@ static void ath9k_wmi_rsp_callback(struct wmi *wmi, struct sk_buff *skb)
>>>  {
>>>  	skb_pull(skb, sizeof(struct wmi_cmd_hdr));
>>>  
>>> -	if (wmi->cmd_rsp_buf != NULL && wmi->cmd_rsp_len != 0)
>>> +	if (wmi->cmd_rsp_buf && wmi->cmd_rsp_len) {
>>> +		if (skb->len < wmi->cmd_rsp_len) {
>>> +			wmi->cmd_rsp_status = -EMSGSIZE;
>>
>> my review agent notes that if this path is taken that there is no debug
>> message alerting this. see my suggestion on dealing with this below...
> 
> I think you're being pedantic here. I'm pretty sure there's no real
> hardware that does this; merging this is meant to protect against a
> USB device pretending to be an ath9k_htc and trying to exploit the
> kernel. So I think it's fine to merge as-is.
And I'm fine with that.

/jeff