Linux wireless drivers development
 help / color / mirror / Atom feed
From: "Jérôme Pouiller" <jerome.pouiller@silabs.com>
To: linux-wireless@vger.kernel.org,
	Johannes Berg <johannes@sipsolutions.net>
Cc: linux-kernel@vger.kernel.org, linux-devel@silabs.com,
	"Alexander Sverdlin" <alexander.sverdlin@siemens.com>,
	"Lukas Stockmann" <lukas.stockmann@siemens.com>,
	"Gerard Salvatella" <gerard.salvatella@siemens.com>,
	"Jérôme Pouiller" <jerome.pouiller@silabs.com>
Subject: [PATCH wireless-next 1/2] wifi: wfx: fix use-after-free of the cooling work on device removal
Date: Sun,  6 Sep 2026 22:47:28 +0200	[thread overview]
Message-ID: <20260906204831.949692-2-jerome.pouiller@silabs.com> (raw)
In-Reply-To: <20260906204831.949692-1-jerome.pouiller@silabs.com>

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>
---
 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);
 }
 
-- 
2.47.3


  reply	other threads:[~2026-09-06 20:49 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 ` Jérôme Pouiller [this message]
2026-09-07  9:11   ` [PATCH wireless-next 1/2] wifi: wfx: fix use-after-free of the cooling work on device removal Sverdlin, Alexander
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=20260906204831.949692-2-jerome.pouiller@silabs.com \
    --to=jerome.pouiller@silabs.com \
    --cc=alexander.sverdlin@siemens.com \
    --cc=gerard.salvatella@siemens.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