From: Cong Nguyen <congnt264@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Simon Guinot <sguinot@lacie.com>,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2] hwmon: (gpio-fan) fix use-after-free of alarm_work on unbind
Date: Tue, 15 Sep 2026 10:54:09 +0700 [thread overview]
Message-ID: <20260915035409.4177780-1-congnt264@gmail.com> (raw)
fan_alarm_irq_handler() schedules alarm_work, but nothing ever cancels
it. free_irq() (via devm) only waits for an in-progress IRQ handler,
not queued work -- a pending alarm_work can run after fan_data is
devm-freed, dereferencing it in fan_alarm_notify().
Cancel it via a devm action registered before devm_request_irq(), so
teardown frees the IRQ first, then cancels whatever's already queued.
Guenter pointed out cancel_work_sync() still leaves a window if
something schedules the work again after it's canceled; use
disable_work_sync() instead, which permanently disables it too.
Fixes: d6fe1360f42e ("hwmon: add generic GPIO fan driver")
Reported-by: Sashiko AI review <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/r/20260830152150.27F5F1F000E9@smtp.kernel.org
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
---
Changes in v2:
- Use disable_work_sync() instead of cancel_work_sync(), per Guenter:
cancel_work_sync() only drains the current instance, so anything
that calls schedule_work() again afterward would still requeue it.
disable_work_sync() permanently disables the work item too.
drivers/hwmon/gpio-fan.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 084828e1e281..28cfd50aa859 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -81,9 +81,16 @@ static ssize_t fan1_alarm_show(struct device *dev,
static DEVICE_ATTR_RO(fan1_alarm);
+static void gpio_fan_cancel_alarm_work(void *data)
+{
+ struct gpio_fan_data *fan_data = data;
+
+ disable_work_sync(&fan_data->alarm_work);
+}
+
static int fan_alarm_init(struct gpio_fan_data *fan_data)
{
- int alarm_irq;
+ int alarm_irq, err;
struct device *dev = fan_data->dev;
/*
@@ -95,6 +102,17 @@ static int fan_alarm_init(struct gpio_fan_data *fan_data)
return 0;
INIT_WORK(&fan_data->alarm_work, fan_alarm_notify);
+
+ /*
+ * Register before devm_request_irq() below: LIFO teardown must free
+ * the IRQ (stopping new schedule_work() calls) before this cancels
+ * whatever alarm_work is already queued or running.
+ */
+ err = devm_add_action_or_reset(dev, gpio_fan_cancel_alarm_work,
+ fan_data);
+ if (err)
+ return err;
+
irq_set_irq_type(alarm_irq, IRQ_TYPE_EDGE_BOTH);
return devm_request_irq(dev, alarm_irq, fan_alarm_irq_handler,
IRQF_SHARED, "GPIO fan alarm", fan_data);
--
2.25.1
reply other threads:[~2026-09-15 3:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260915035409.4177780-1-congnt264@gmail.com \
--to=congnt264@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=sguinot@lacie.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
all inboxes | Powered by JetHome®