Re: [PATCH 3/3] watchdog: qcom: Register pretimeout interrupt as NMI

[email protected] Thu, 30 Jul 2026 21:44:40 +0000
Newsgroups org.kernel.vger.linux-watchdog
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [High] Potential Use-After-Free and NULL pointer dereference in NMI teard=
own during driver unbind or probe failure.
--

--- Patch [3]: [PATCH 3/3] watchdog: qcom: Register pretimeout interrupt as=
 NMI ---
commit 630edce3072ee30140f775e46b40445975b0d011
Author: Mayank Rungta <[email protected]>

watchdog: qcom: Register pretimeout interrupt as NMI

Attempt to register the pretimeout interrupt as an NMI, falling back to a
standard IRQ if NMI registration fails. Explicitly arm and disarm the NMI
during start and stop operations, and register a devres action to free the
NMI on teardown.

> diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
> index 49bd04841f0c8..19d8e91cff408 100644
> --- a/drivers/watchdog/qcom-wdt.c
> +++ b/drivers/watchdog/qcom-wdt.c

[ ... ]

> +static void qcom_wdt_free_nmi(void *arg)
> +{
> +	struct qcom_wdt *wdt =3D arg;
> +
> +	qcom_wdt_disable_irq(wdt);
> +	free_nmi(wdt->irq, &wdt->wdd);

[Severity: High]
Is there a regression here that could cause a use-after-free during driver
unbind or probe failure?

Unlike free_irq(), free_nmi() does not synchronize with in-flight NMI handl=
ers
on other CPUs. It immediately clears desc->action and calls kfree() on the
struct irqaction.

If the pretimeout NMI triggers concurrently just before the interrupt is
masked, could the architecture NMI handler be executing and dereference the
freed irqaction?

kernel/irq/chip.c:handle_fasteoi_nmi() {
    ...
    res =3D action->handler(irq, action->dev_id);
    ...
}

Additionally, since subsequent devres unwinding frees the struct qcom_wdt,
could qcom_wdt_isr() also dereference the freed wdd pointer when calling
watchdog_notify_pretimeout(wdd)?

Could this be triggered by root via sysfs unbind, or naturally during a
hardware-induced pretimeout racing with a module unload, leading to a crash?

> +}

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260730-qcom-wdt-n=
[email protected]?part=3D3