Messages in this thread | | | From | Toke Høiland-Jørgensen <> | Subject | Re: [PATCH v3 2/2] wifi: ath9k: protect WMI command response buffer replacement with a lock | Date | Tue, 08 Aug 2023 16:07:57 +0200 |
| |
Fedor Pchelkin <pchelkin@ispras.ru> writes:
> If ath9k_wmi_cmd() has exited with a timeout, it is possible that during > next ath9k_wmi_cmd() call the wmi_rsp callback for previous wmi command > writes to new wmi->cmd_rsp_buf and makes a completion. This results in an > invalid ath9k_wmi_cmd() return value. > > Move the replacement of WMI command response buffer and length under > wmi_lock. Note that last_seq_id value is updated there, too. > > Thus, the buffer cannot be written to by a belated wmi_rsp callback > because that path is properly rejected by the last_seq_id check. > > Found by Linux Verification Center (linuxtesting.org) with Syzkaller. > > Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") > Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Given that the previous patch resets the last_seq_id to 0 on timeout under the lock, I don't think this patch is strictly necessary anymore. However, it doesn't hurt either, and I actually think moving the update of the rsp buf into ath9k_wmi_cmd_issue() aids readability, so:
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
| |