Re: [PATCH] mwifiex: Fix use-after-free bug due to race condition between main thread thread and timer thread

[Zheng Hacker]

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