Re: [PATCH] hwmon: (gpio-fan) return IRQ_HANDLED from the shared alarm IRQ handler

[sashiko-bot@kernel.org]

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

New issues:
- [High] The interrupt handler unconditionally returns IRQ_HANDLED while registered as IRQF_SHARED, neutralizing spurious interrupt detection and risking a CPU lockup.

Pre-existing issues:
- [High] Missing cancellation of `alarm_work` during driver unbind leads to a Use-After-Free vulnerability.
--

commit 2cca5798d0ba1012484e76e484ce607c8ed4c2f0
Author: Cong Nguyen <congnt264@gmail.com>

hwmon: (gpio-fan) return IRQ_HANDLED from the shared alarm IRQ handler

This commit changes the interrupt handler for the GPIO fan alarm to return
IRQ_HANDLED instead of IRQ_NONE to prevent the spurious interrupt detector
from disabling the shared line.

Link: https://lore.kernel.org/r/20260830152150.27F5F1F000E9@smtp.kernel.org

> diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
> index 084828e1e2817..a55a7ea07fc01 100644
> --- a/drivers/hwmon/gpio-fan.c
> +++ b/drivers/hwmon/gpio-fan.c
> @@ -67,7 +67,7 @@ static irqreturn_t fan_alarm_irq_handler(int irq, void *dev_id)
>  
>  	schedule_work(&fan_data->alarm_work);

[Severity: High]
This is a pre-existing issue, but does this workqueue lack a cancellation
mechanism during driver unbind? The alarm_work is scheduled here and
executed asynchronously in fan_alarm_notify(), but there doesn't appear
to be a registered devm cleanup action to ensure cancel_work_sync() is
called during teardown.

If the device is unbound via sysfs while an alarm condition exists, devres
first frees the IRQ line and then the fan_data structure without waiting
for pending system workqueues. Could this result in a use-after-free
vulnerability when the delayed work executes and dereferences the freed
fan_data memory in fan_alarm_notify()?

>  
> -	return IRQ_NONE;
> +	return IRQ_HANDLED;

[Severity: High]
Does this code unconditionally claim every interrupt on the shared line?

Since this handler is registered with IRQF_SHARED, always returning
IRQ_HANDLED could mask spurious interrupts from other devices sharing
the line. This prevents the core IRQ subsystem from detecting and
disabling a faulty line, which might lead to an unmitigated interrupt
storm and a CPU lockup.

Should the handler verify if the interrupt was actually generated by the
GPIO fan alarm hardware before returning IRQ_HANDLED?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901155648.1538876-1-congnt264@gmail.com?part=1