[PATCH] iio: trigger: cancel reenable_work before freeing trigger

[PATCH] iio: trigger: cancel reenable_work before freeing trigger

[Fan Wu]

iio_trigger_notify_done_atomic() defers ->reenable() into
trig->reenable_work on the system workqueue, and the worker dereferences
the owning trigger through container_of().  Nothing cancels this work
before iio_trig_release() frees the trigger, so a worker armed by the
last in-flight IRQ can outlive the free and touch freed memory.

Cancel it at the top of iio_trig_release(), which every free path
reaches through the device core's final put_device().

Found by an in-house static analysis tool.

Fixes: 9020ef659885 ("iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046")
Cc: stable@vger.kernel.org
Cc: Jonathan Cameron <jic23@kernel.org>
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
 drivers/iio/industrialio-trigger.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
index 54416a384232..68e92eac2b77 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -509,6 +509,8 @@ static void iio_trig_release(struct device *device)
 	struct iio_trigger *trig = to_iio_trigger(device);
 	int i;
 
+	cancel_work_sync(&trig->reenable_work);
+
 	if (trig->subirq_base) {
 		for (i = 0; i < CONFIG_IIO_CONSUMERS_PER_TRIGGER; i++) {
 			irq_modify_status(trig->subirq_base + i,
-- 
2.34.1

Re: [PATCH] iio: trigger: cancel reenable_work before freeing trigger

[Jonathan Cameron]

On Thu,  6 Aug 2026 14:25:02 +0000
Fan Wu <fanwu01@zju.edu.cn> wrote:

> iio_trigger_notify_done_atomic() defers ->reenable() into
> trig->reenable_work on the system workqueue, and the worker dereferences
> the owning trigger through container_of().  Nothing cancels this work
> before iio_trig_release() frees the trigger, so a worker armed by the
> last in-flight IRQ can outlive the free and touch freed memory.
> 
> Cancel it at the top of iio_trig_release(), which every free path
> reaches through the device core's final put_device().
> 
> Found by an in-house static analysis tool.
> 
> Fixes: 9020ef659885 ("iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046")
> Cc: stable@vger.kernel.org
> Cc: Jonathan Cameron <jic23@kernel.org>
> Assisted-by: Codex:gpt-5.6
> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Logic seems correct to me.  Applied to the fixes-togreg branch of iio.git.

Note the only way we can see this in practice requires a race with a race handler
closing bit of code. Having said that, the inner one of those races handlers is
occasionally needed, so fair enough that we need to fix this.

Jonathan

> ---
>  drivers/iio/industrialio-trigger.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
> index 54416a384232..68e92eac2b77 100644
> --- a/drivers/iio/industrialio-trigger.c
> +++ b/drivers/iio/industrialio-trigger.c
> @@ -509,6 +509,8 @@ static void iio_trig_release(struct device *device)
>  	struct iio_trigger *trig = to_iio_trigger(device);
>  	int i;
>  
> +	cancel_work_sync(&trig->reenable_work);
> +
>  	if (trig->subirq_base) {
>  		for (i = 0; i < CONFIG_IIO_CONSUMERS_PER_TRIGGER; i++) {
>  			irq_modify_status(trig->subirq_base + i,