Re: [PATCH v5 2/3] drm/xe/xe_ras: Report correctable error events to userspace

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing bounds check on the hardware-provided `component` value before using it in the `BIT(component)` macro, leading to undefined behavior (shift out of bounds) and failure of the deduplication logic.
--

--- Patch [2]: [PATCH v5 2/3] drm/xe/xe_ras: Report correctable error events to userspace ---
commit 5a086f0455803475a13c848290347fe3571d79fa
Author: Riana Tauro <riana.tauro@intel.com>

drm/xe/xe_ras: Report correctable error events to userspace

When an interrupt indicates the error counter has crossed its threshold,
this commit reads the current counter value and delivers a drm_ras error
event to userspace. It also attempts to send the error event only once
per component.

> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index ed609912fda14..cf85075d62667 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c
[ ... ]
> @@ -241,8 +293,10 @@ void xe_ras_counter_threshold_crossed(struct xe_device *xe,
>  	struct xe_ras_threshold_crossed *pending = (void *)&response->data;
>  	struct xe_ras_error_class *errors = pending->counters;
>  	u32 id, ncounters = pending->ncounters;
> +	u8 sent = 0;
>  
>  	BUILD_BUG_ON(sizeof(response->data) < sizeof(*pending));
> +	BUILD_BUG_ON(BITS_PER_TYPE(sent) < XE_RAS_COMP_MAX);
>  	xe_device_assert_mem_access(xe);
>  
>  	if (!ncounters || ncounters > XE_RAS_NUM_COUNTERS)
> @@ -256,8 +310,21 @@ void xe_ras_counter_threshold_crossed(struct xe_device *xe,
>  		severity = errors[id].common.severity;
>  		component = errors[id].common.component;
>  
> +		if (severity != XE_RAS_SEV_CORRECTABLE) {
> +			xe_warn(xe, "sysctrl: unexpected severity %s (%u)\n", sev_to_str(severity),
> +				severity);
> +			continue;
> +		}
> +
>  		xe_warn(xe, "[RAS]: %s %s detected\n",
>  			comp_to_str(component), sev_to_str(severity));
> +
> +		/* Send event once per component */
> +		if (sent & BIT(component))
> +			continue;
> +		sent |= BIT(component);

[Severity: High]
Since component comes directly from the firmware response in
errors[id].common.component, could this cause a shift out of bounds or
truncation if the firmware sends an unexpected component ID?

If component >= 8, BIT(component) evaluates to 256 or larger. When this is
bitwise-ORed into the u8 sent mask, it truncates to 0 and the deduplication
logic fails. If component >= 64, this will trigger a shift out of bounds.

Should there be a bounds check against XE_RAS_COMP_MAX before using the
component value in the BIT() macro?

> +
> +		ras_send_error_event(xe, severity, component);
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720082208.2648279-5-riana.tauro@intel.com?part=2