Re: [PATCH v6 01/18] platform/x86/intel/pmt: complete pcidev to device update

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the telemetry endpoint struct (`ep`) can be accessed after its MMIO memory is unmapped because `ep->present` is not set to `false` during device removal.
- [High] This problem wasn't introduced by this patch, but there is an unconditional bad cast of a generic device to a PCI device using `to_pci_dev()`, causing undefined behavior for ACPI-based PMT devices.
--

commit b960ebec46fe99a17e1ecbb42ea33da55296b489
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>

    platform/x86/intel/pmt: complete pcidev to device update
    
    The update that moved struct pci_dev usage to struct device is
    incomplete. Only telemetry endpoints are covered.
    
    Other PMT features (crashlog) are now blocked from using the callback
    mechanism.
    
    Change struct intel_pmt_entry pci_dev member to device.
    
    Update callback usage to use the intel_pmt_entry rather than the
    telemetry endpoint.
    
    Fixes: 353042d54d82 ("platform/x86/intel/vsec: Switch exported helpers from pci_dev to device")

> diff --git a/drivers/platform/x86/intel/pmt/class.h b/drivers/platform/x86/intel/pmt/class.h
> index a0ece4fc3837d..258cb460e61c2 100644
> --- a/drivers/platform/x86/intel/pmt/class.h
> +++ b/drivers/platform/x86/intel/pmt/class.h
> @@ -42,7 +41,7 @@ struct intel_pmt_header {
>  
>  struct intel_pmt_entry {
>  	struct telem_endpoint	*ep;
> -	struct pci_dev		*pcidev;
> +	struct device		*dev;

[Severity: High]
This problem wasn't introduced by this patch, but while reviewing the changes
to struct intel_pmt_entry, I noticed a potential type confusion issue in
drivers/platform/x86/intel/pmt/telemetry.c:

drivers/platform/x86/intel/pmt/telemetry.c:pmt_copy_region() {
    struct pci_dev *pdev = to_pci_dev(entry->ep->dev);
    ...
}

Can this unconditional cast of a generic device to a PCI device cause
undefined behavior for ACPI-based PMT devices?

PMT telemetry devices can be discovered via ACPI (e.g., INTEL_VSEC_DISC_ACPI
used in pwrm_telemetry.c and ssram_telemetry.c). In this case, entry->ep->dev
points to an ACPI platform device, not a PCI device.

When pmt_copy_region() blindly calls to_pci_dev(entry->ep->dev), it uses
container_of to subtract a large offset. The resulting garbage pointer is
passed to intel_vsec_get_mapping(), which passes it to pci_match_id(). This
causes a dereference of PCI-specific struct fields like vendor and device
from unmapped or unrelated memory, leading to an out-of-bounds read and
likely kernel panic.

This appears to be reachable unconditionally when consumers like resctrl
iterate over telemetry endpoints and call intel_pmt_get_regions_by_feature()
which in turn calls pmt_copy_region() on systems using ACPI-based PMT
devices.


[Severity: High]
This problem wasn't introduced by this patch, but the telemetry endpoint
struct (ep) can be accessed after its MMIO memory is unmapped because
ep->present is not set to false during device removal.

Looking at drivers/platform/x86/intel/pmt/telemetry.c:pmt_telem_remove():

    for (i = 0; i < priv->num_entries; i++) {
        struct intel_pmt_entry *entry = &priv->entry[i];

        kref_put(&entry->ep->kref, pmt_telem_ep_release);
        intel_pmt_dev_destroy(entry, &pmt_telem_ns);
    }

Can this lead to a use-after-free of MMIO memory?

A consumer (like resctrl or intel_pmc_core) requests a telemetry endpoint
via pmt_telem_find_and_register_endpoint(), holding a kref to the
endpoint.

If the PMT device is subsequently unbound or hot-removed,
pmt_telem_remove() drops the driver's reference. The devres framework then
unmaps entry->base (which aliases to ep->base).

Because ep->present is never set to false, the consumer will bypass the
if (!ep->present) safety checks and attempt to read from the now-unmapped
ep->base MMIO address.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904182451.1164868-20-michael.j.ruhl@intel.com?part=1