Re: [PATCH wireless-next v2 1/2] wifi: wfx: fix possible device hang during init

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Uncanceled delayed work triggers Use-After-Free.
--

commit 0e92ce2797177a88d76cee72478042230234d0a4
Author: Jérôme Pouiller <jerome.pouiller@silabs.com>

wifi: wfx: fix possible device hang during init

This commit fixes a device hang by limiting the use of the data polling
mechanism to out-of-band SDIO IRQs. For in-band IRQs and SPI, the IRQ is
now subscribed before the first hardware exchange, avoiding the polling
workaround entirely.

> diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> index dda36e41eed13..4e99fe7e5bb78 100644
> --- a/drivers/net/wireless/silabs/wfx/main.c
> +++ b/drivers/net/wireless/silabs/wfx/main.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed a potential use-after-free in the
driver cleanup path. When the device enters a high temperature state,
wfx_suspend_hot_dev() schedules cooling_timeout_work on the system workqueue
with a 10-second delay.

If the driver is unloaded or the device is removed before this timer expires,
the devres callback wfx_free_common() frees the wdev structure without
canceling the pending work:

drivers/net/wireless/silabs/wfx/main.c:wfx_free_common() {
    ...
    ieee80211_free_hw(wdev->hw);
    ...
}

Does the cleanup path need a call to cancel_delayed_work_sync() for
wdev->cooling_timeout_work to prevent the delayed work from dereferencing
the freed wdev pointer when it eventually executes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901083548.113131-1-jerome.pouiller@silabs.com?part=1