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

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jeff Johnson <jeff.johnson@oss.qualcomm.com> 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@iscas.ac.cn>
>> ---
>> Changes since v1: https://lore.kernel.org/all/20260704011405.55089-1-pengpeng@iscas.ac.cn/
>> - 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.

-Toke