From: "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>
To: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
"jerome.pouiller@silabs.com" <jerome.pouiller@silabs.com>
Cc: "linux-devel@silabs.com" <linux-devel@silabs.com>,
"Stockmann, Lukas" <lukas.stockmann@siemens.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Salvatella, Gerard" <gerard.salvatella@siemens.com>
Subject: Re: [PATCH wireless-next 1/2] wifi: wfx: fix use-after-free of the cooling work on device removal
Date: Mon, 7 Sep 2026 09:11:58 +0000 [thread overview]
Message-ID: <9ae51d750e3b52e11abf87b2f4f42708f6dd9fb1.camel@siemens.com> (raw)
In-Reply-To: <20260906204831.949692-2-jerome.pouiller@silabs.com>
Hi Jérôme,
On Sun, 2026-09-06 at 22:47 +0200, Jérôme Pouiller wrote:
> When the device reports that it is too hot, wfx_suspend_hot_dev() blocks
> the Tx queues and arms cooling_timeout_work with a 10s delay. If the
> device recovers a normal temperature before the delay expires, the work
> is canceled. Else, the work declares the chip frozen and unblocks the Tx
> queues.
>
> However, this work is never canceled when the device is removed.
> cooling_timeout_work is queued on the system workqueue, while struct
> wfx_dev is released by wfx_free_common() (through ieee80211_free_hw()).
> So, if the device is unbound during this 10s window, the work fires
> after struct wfx_dev has been freed and dereferences it.
>
> Cancel the work during the teardown. It has to be done after
> wfx_bh_unregister(): the "device too hot" indication is processed by the
> bh, so canceling the work earlier would allow the bh to rearm it. On the
> other hand, the work calls wfx_tx_unlock(), which may in turn call
> wfx_bh_request_tx(). So it has to be canceled before bh_wq is destroyed.
>
> Note that the Tx queues are intentionally left blocked: the device is
> going away, so there is nothing to unblock.
>
> The issue was reported by the Sashiko review bot and the fix has been
> written by Copilot (including the commit log). The use-case is difficult
> to reproduce, so this code has not been tested. However, I don't believe
> this patch could cause any regression.
>
> Fixes: 1d52d29983e5d ("staging: wfx: add support for 'device too hot' indication")
> Assisted-by: Sashiko:gemini-3.1-pro-preview
> Assisted-by: Copilot:claude-opus-5
> Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
thanks for the patch! Tested with rmmod, no regression visible,
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> ---
> drivers/net/wireless/silabs/wfx/main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> index 4e99fe7e5bb78..b6fd9d4c1f5fc 100644
> --- a/drivers/net/wireless/silabs/wfx/main.c
> +++ b/drivers/net/wireless/silabs/wfx/main.c
> @@ -487,6 +487,7 @@ int wfx_probe(struct wfx_dev *wdev)
> wdev->hwbus_ops->irq_unsubscribe(wdev->hwbus_priv);
> bh_unregister:
> wfx_bh_unregister(wdev);
> + cancel_delayed_work_sync(&wdev->cooling_timeout_work);
> destroy_workqueue(wdev->bh_wq);
> return err;
> }
> @@ -497,6 +498,7 @@ void wfx_release(struct wfx_dev *wdev)
> wfx_hif_shutdown(wdev);
> wdev->hwbus_ops->irq_unsubscribe(wdev->hwbus_priv);
> wfx_bh_unregister(wdev);
> + cancel_delayed_work_sync(&wdev->cooling_timeout_work);
> destroy_workqueue(wdev->bh_wq);
> }
--
Alexander Sverdlin
Siemens AG
www.siemens.com
next prev parent reply other threads:[~2026-09-07 9:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 20:47 [PATCH wireless-next 0/2] wifi: wfx: fix two minor issues in error paths Jérôme Pouiller
2026-09-06 20:47 ` [PATCH wireless-next 1/2] wifi: wfx: fix use-after-free of the cooling work on device removal Jérôme Pouiller
2026-09-07 9:11 ` Sverdlin, Alexander [this message]
2026-09-06 20:47 ` [PATCH wireless-next 2/2] wifi: wfx: fix error code on unsupported firmware Jérôme Pouiller
2026-09-07 6:20 ` Sverdlin, Alexander
2026-09-07 6:59 ` Jérôme Pouiller
2026-09-07 7:05 ` Sverdlin, Alexander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ae51d750e3b52e11abf87b2f4f42708f6dd9fb1.camel@siemens.com \
--to=alexander.sverdlin@siemens.com \
--cc=gerard.salvatella@siemens.com \
--cc=jerome.pouiller@silabs.com \
--cc=johannes@sipsolutions.net \
--cc=linux-devel@silabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lukas.stockmann@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).