Brian Norris <briannorris@xxxxxxxxxxxx> 于2023年2月22日周三 11:31写道： > > On Sat, Feb 18, 2023 at 03:59:56PM +0800, Zheng Wang wrote: > > Note that, this bug is found by static analysis, it could be wrong. We > > could discuss that before writing the fix. > > Yeah, please don't accept this patch. It deserves an "RFC" in the title > at best. Sure, it's an identified race condition, but the cure here > (deleting all possible recovery from firmware crashes) is worse than the > disease. > Hello Brain, Thanks for your reply. I do need add "RFC" in the title. Sorry about that. The invoking chain is as descriped in the original mail. There is some place which may confuse you. In mwifiex_exec_next_cmd function, the adapter is got from cmd_node->priv->adapter. You might think if this is the same adapter in outer function. In mwifiex_register function, it inits the priv_arrary with adapter->priv[i]->adapter = adapter, Then use mwifiex_init_lock_list to init the list. When it fetch adapter like calling mwifiex_cfg80211_get_tx_power, it travers the array to find the target priv. So all the adapter paramter is pointed to the same adapter. The UAF of it is vulnerable. In summary, after the firmware is downloaded, it will start the timer function, which is known as mwifiex_cmd_timeout_func. The if_ops.card_reset function pointer is assigned with mwifiex_sdio_card_reset, which will schedule_work the card->work. It finally pass the check becauese card->work_flags has MWIFIEX_IFACE_WORK_CARD_RESET. Finnaly, in _mwifiex_fw_dp, if init is failed, it will call mwifiex_free_adapter and free the adapter. > There's no real attempt at analyzing the race or providing solutions, so > there's not much to discuss yet. Yes, I did't figure out a good plan to fix. As I say, it free the adapter in the error handling path. Could you please provide some advice about the fix? Best regards, Zheng
