All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 05/10] drm/xe/vsec: Support possible hotplug exit
Date: Wed, 12 Aug 2026 19:51:49 +0000	[thread overview]
Message-ID: <20260812195149.E569F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812193742.2170188-17-michael.j.ruhl@intel.com>

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

Pre-existing issues:
- [High] The `xe_pmt_telem_read` function performs a `memcpy_fromio` without validating that the requested telemetry read fits within the `xe->mmio.regs` mapped region. The `user_offset` and `count` parameters passed from the sysfs interface are bounded by `entry->size` (derived from the device's PMT discovery header). However, the hardware-provided size is implicitly trusted and never validated against the driver's actual MMIO mapping limits. A malicious or buggy hardware device could advertise an artificially large `header->size`, bypassing the `sysfs` offset limits. Because `xe_pmt_telem_read` calculates `telem_addr = xe->mmio.regs + offset + user_offset` and performs `memcpy_fromio`, this permits an out-of-bounds read past the end of the `xe->mmio.regs` mapping. Reading arbitrary unmapped physical memory or unrelated device registers could cause a system crash, leak sensitive hardware state, or trigger unintended side effects from read-sensitive registers.
--

--- Patch [5]: [PATCH v2 05/10] drm/xe/vsec: Support possible hotplug exit ---
commit 240693c221b75275ccbcc4f83244797a5eb5edf9
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>

drm/xe/vsec: Support possible hotplug exit

This patch adds drm_dev_enter() and drm_dev_exit() to xe_pmt_telem_read()
to verify the device is valid in the hotplug context before accessing it. It
also updates error handling to properly exit the DRM device context on failure.

> diff --git a/drivers/gpu/drm/xe/xe_vsec.c b/drivers/gpu/drm/xe/xe_vsec.c
> --- a/drivers/gpu/drm/xe/xe_vsec.c
> +++ b/drivers/gpu/drm/xe/xe_vsec.c
[ ... ]
> @@ -148,14 +155,20 @@ int xe_pmt_telem_read(struct device *dev, u32 guid, u64 *data, loff_t user_offse
>  	u32 cap_type = FIELD_GET(GUID_CAP_TYPE, guid);
>  	u32 mem_region;
>  	u32 offset;
> -	int ret;
> +	int ret = 0;
> +	int idx;
>  
> -	if (!xe->soc_remapper.set_telem_region)
> +	if (!drm_dev_enter(&xe->drm, &idx))
>  		return -ENODEV;
>  
> +	if (!xe->soc_remapper.set_telem_region) {
> +		ret = -EINVAL;
> +		goto dev_exit;
> +	}
> +
>  	ret = xe_guid_decode(guid, &mem_region, &offset);
>  	if (ret)
> -		return ret;
> +		goto dev_exit;
>  
>  	telem_addr += offset + user_offset;

[Severity: High]
This is a pre-existing issue, but does this code need to validate that the
requested telemetry read fits within the xe->mmio.size limit?

If a device provides a malicious or buggy PMT discovery header that advertises a
large entry->size, the sysfs offset limits would allow large user_offset and
count values.

Could the subsequent memcpy_fromio(data, telem_addr, count) further down in this
function then read past the end of the xe->mmio.regs mapping, potentially
causing a crash or leaking state from unmapped or read-sensitive registers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812193742.2170188-12-michael.j.ruhl@intel.com?part=5

  reply	other threads:[~2026-08-12 22:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 19:37 [PATCH v2 00/10] Crescent Island PMT support Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 01/10] platform/x86/intel/pmt: complete pcidev to device update Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 02/10] platform/x86/intel/pmt: Add register access callbacks Michael J. Ruhl
2026-08-12 19:49   ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 03/10] drm/xe/vsec: Protect against missing config Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 04/10] drm/xe/vsec: Use correct pm state get Michael J. Ruhl
2026-08-12 19:37 ` [PATCH v2 05/10] drm/xe/vsec: Support possible hotplug exit Michael J. Ruhl
2026-08-12 19:51   ` sashiko-bot [this message]
2026-08-12 19:37 ` [PATCH v2 06/10] drm/xe/vsec: Support Crescent Island PMT Michael J. Ruhl
2026-08-12 19:49   ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 07/10] drm/xe/vsec: Crescent Island PMT decode Michael J. Ruhl
2026-08-12 19:51   ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 08/10] drm/xe/vsec: Crescent Island PMT callbacks Michael J. Ruhl
2026-08-12 19:57   ` sashiko-bot
2026-08-12 19:37 ` [PATCH v2 09/10] drm/xe/vsec: Support late bind fw information Michael J. Ruhl
2026-08-12 19:54   ` sashiko-bot
2026-08-12 20:12   ` Ruhl, Michael J
2026-08-12 19:37 ` [PATCH v2 10/10] drm/xe/vsec: Update PMT internal access for CRI Michael J. Ruhl
2026-08-12 20:04   ` sashiko-bot
2026-08-12 20:24 ` ✓ CI.KUnit: success for Crescent Island PMT support (rev4) Patchwork
2026-08-12 21:16 ` ✓ Xe.CI.BAT: " Patchwork

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=20260812195149.E569F1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=michael.j.ruhl@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.