From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
To: Fan Wu <fanwu01@zju.edu.cn>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Lukasz Luba <lukasz.luba@arm.com>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Song Li <songl@zju.edu.cn>
Subject: Re: [PATCH] thermal: intel: int340x: Fix use-after-free in proc_thermal_pci
Date: Wed, 23 Sep 2026 10:32:53 -0700 [thread overview]
Message-ID: <6f4801cacb3f4c81905bd85567c32b0b4e3aaa5a.camel@linux.intel.com> (raw)
In-Reply-To: <20260923072730.487900-1-fanwu01@zju.edu.cn>
On Wed, 2026-09-23 at 07:27 +0000, Fan Wu wrote:
> proc_thermal_pci_remove() cancels pci_info->work before disabling the
> interrupt sources that schedule it. A threshold IRQ which arrives
> after
> the cancel but before the THRES_0 and INT_ENABLE_0 MMIO mask makes
> proc_thermal_irq_handler() reschedule the work, so
> proc_thermal_threshold_work_fn() runs after devm cleanup has freed
> pci_info and dereferences pci_info->tzone and proc_priv->mmio_base.
> The
> shared IRQ is never freed in remove(), which widens the window, and
> the
> probe error paths never cancel the work either.
>
> Fix this by cutting off the producers before draining: mask the
> THRES_0
> and INT_ENABLE_0 registers, free the MSI interrupts or the shared
> IRQ,
> and only then cancel the delayed work. The probe error paths cancel
> the
> work before the thermal zone is unregistered.
>
> The work function re-enables the INT_ENABLE_0 bit, but the IRQs are
> already freed when it is cancelled and THRES_0 stays cleared, so
> nothing
> can schedule the work again.
>
> This issue was found by an in-house static analysis tool.
>
> Fixes: acd65d5d1cf4 ("thermal/drivers/int340x/processor_thermal: Add
> PCI MMIO based thermal driver")
> Cc: stable@vger.kernel.org
> Co-developed-by: Song Li <songl@zju.edu.cn>
> Signed-off-by: Song Li <songl@zju.edu.cn>
> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> .../processor_thermal_device_pci.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git
> a/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci.
> c
> b/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci.
> c
> index c693d93..1856e76 100644
> ---
> a/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci.
> c
> +++
> b/drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci.
> c
> @@ -409,7 +409,10 @@ static int proc_thermal_pci_probe(struct pci_dev
> *pdev, const struct pci_device_
> err_free_vectors:
> if (msi_irq)
> proc_thermal_free_msi(pdev, pci_info);
> + else
> + devm_free_irq(&pdev->dev, pdev->irq, pci_info);
> err_ret_tzone:
> + cancel_delayed_work_sync(&pci_info->work);
> thermal_zone_device_unregister(pci_info->tzone);
> err_del_legacy:
> if (!pci_info->no_legacy)
> @@ -424,13 +427,16 @@ static void proc_thermal_pci_remove(struct
> pci_dev *pdev)
> struct proc_thermal_device *proc_priv =
> pci_get_drvdata(pdev);
> struct proc_thermal_pci *pci_info = proc_priv->priv_data;
>
> - cancel_delayed_work_sync(&pci_info->work);
> -
> proc_thermal_mmio_write(pci_info, PROC_THERMAL_MMIO_THRES_0,
> 0);
> proc_thermal_mmio_write(pci_info,
> PROC_THERMAL_MMIO_INT_ENABLE_0, 0);
>
> if (msi_irq)
> proc_thermal_free_msi(pdev, pci_info);
> + else
> + devm_free_irq(&pdev->dev, pdev->irq, pci_info);
> +
> + /* Cancel after the IRQs are freed, or the handler may
> reschedule it. */
> + cancel_delayed_work_sync(&pci_info->work);
>
> thermal_zone_device_unregister(pci_info->tzone);
> proc_thermal_mmio_remove(pdev, pci_info->proc_priv);
next prev parent reply other threads:[~2026-09-23 17:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 7:27 [PATCH] thermal: intel: int340x: Fix use-after-free in proc_thermal_pci Fan Wu
2026-09-23 17:32 ` srinivas pandruvada [this message]
2026-09-25 20:10 ` Rafael J. Wysocki (Intel)
2026-09-29 15:15 ` Fan Wu
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=6f4801cacb3f4c81905bd85567c32b0b4e3aaa5a.camel@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=fanwu01@zju.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=songl@zju.edu.cn \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.