Re: [PATCH v6 14/18] drm/xe/vsec: Crescent Island PMT callbacks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Concurrent telemetry reads during PMT crashlog probe corrupt discovery header decoding, leading to out-of-bounds physical memory mapping.
--

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

drm/xe/vsec: Crescent Island PMT callbacks

This commit introduces callback functions (read_reg, write_reg) and initialization
logic to support Crescent Island (CRI) PMT features, specifically for crashlog
discovery and telemetry via an MMIO region.

> diff --git a/drivers/gpu/drm/xe/xe_vsec.c b/drivers/gpu/drm/xe/xe_vsec.c
> index 22c4efb021328..7c3f9938701e3 100644
> --- a/drivers/gpu/drm/xe/xe_vsec.c
> +++ b/drivers/gpu/drm/xe/xe_vsec.c
[ ... ]
> @@ -396,8 +489,17 @@ void xe_vsec_init(struct xe_device *xe)
>  		if (IS_SRIOV_VF(xe))
>  			return;
>  		xe->pmt.base_offset = BMG_TELEMETRY_OFFSET;
> -		info->priv_data = &xe_pmt_cb;
> +		info->priv_data = &xe_bmg_pmt_cb;
>  		break;
> +
> +	case XE_VSEC_CRI:
> +		if (IS_SRIOV_VF(xe))
> +			return;
> +		xe->pmt.base_offset = CRI_PMT_OFFSET;
> +		info->priv_data = &xe_cri_pmt_cb;
> +		xe->soc_remapper.set_telem_region(xe, CRI_IDX_TELEM_DISCOVERY);

[Severity: High]
Does this sequence allow concurrent telemetry reads to corrupt the PMT
crashlog probe discovery header?

The remapper index is set once during init here, which seems to assume it will
remain unchanged during the sequential PMT core probes. However, if userspace
concurrently reads the telemetry sysfs file, it calls xe_pmt_telem_read()
which modifies the index:

	mutex_lock(&xe->pmt.lock);

	/* set SoC re-mapper index register based on GUID memory region */
	xe->soc_remapper.set_telem_region(xe, mem_region);

	memcpy_fromio(data, telem_addr, count);

	mutex_unlock(&xe->pmt.lock);

Because xe_pmt_telem_read() modifies the shared SoC remapper index but fails
to restore it to CRI_IDX_TELEM_DISCOVERY before unlocking, subsequent
discovery table reads can get permanently corrupted.

If the PMT class driver uses a corrupted discovery header's base_offset
and size to call devm_ioremap_resource(), could this map an uncontrolled
physical address and expose arbitrary physical memory contents to userspace?

> +		break;
> +
>  	default:
>  		break;
>  	}

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