Re: [PATCH v3] drm/xe/guc: Demote uncorrectable local error log on CRI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe/guc: UAF in xe_guc_uncorrectable_error_handler due to missing refcount
--

commit c1812b93b48a6984d3994289c7b05357ce4e4972
Author: Varun Gupta <varun.gupta@intel.com>

drm/xe/guc: Demote uncorrectable local error log on CRI

The UNCORRECTABLE_LOCAL_ERROR notification sent by the GuC indicates a
local, queue-level context termination rather than a global device or
driver failure. This commit demotes the error log to an info log on
CRI platforms to reduce noise from routine workloads.

> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index 0b231228bde8b..6dd0e0eead9c0 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
[ ... ]
> @@ -3569,9 +3569,19 @@ int xe_guc_uncorrectable_error_handler(struct xe_guc *guc, u32 *msg, u32 len)
>  	if (unlikely(!q))
>  		return -EPROTO;
>  
> -	xe_gt_err(gt,
> -		  "GuC: Uncorrectable local error! guc_id=%d class=%s, logical_mask=0x%x",
> -		  guc_id, xe_hw_engine_class_to_str(q->class), q->logical_mask);
> +	/*
> +	 * On CRI, the hardware cannot distinguish GT translation faults
> +	 * from true RAS conditions. Demote to info to avoid false-positive
> +	 * hardware error logs.
> +	 */
> +	if (gt_to_xe(gt)->info.platform == XE_CRESCENTISLAND)
> +		xe_gt_info(gt,
> +			   "GuC: Uncorrectable local error! guc_id=%d class=%s, logical_mask=0x%x",
> +			   guc_id, xe_hw_engine_class_to_str(q->class), q->logical_mask);
> +	else
> +		xe_gt_err(gt,
> +			  "GuC: Uncorrectable local error! guc_id=%d class=%s, logical_mask=0x%x",
> +			  guc_id, xe_hw_engine_class_to_str(q->class), q->logical_mask);

[Severity: High]
Can this sequence lead to a use-after-free on the queue pointer?

The uncorrectable error handler uses g2h_exec_queue_lookup(), which retrieves
the queue pointer via xa_load() without taking a reference count. If the
device is wedged or GuC firmware is stopped concurrently, the scheduler's
cleanup worker can bypass the synchronous wait for GuC's deregistration
and call guc_exec_queue_destroy_async(q):

__guc_exec_queue_process_msg_cleanup() {
    ...
    if (bound && !exec_queue_wedged(q) && exec_queue_registered(q) &&
        xe_uc_fw_is_running(&guc->fw))
        disable_scheduling_deregister(guc, q);
    else
        guc_exec_queue_destroy_async(q);
}

This asynchronously schedules the queue's destruction and immediately frees
its memory via kfree(q) instead of kfree_rcu():

__xe_exec_queue_free() {
    ...
    kvfree(q->replay_state);
    kfree(q);
}

Since the G2H worker processing xe_guc_uncorrectable_error_handler() holds
no reference, couldn't the queue memory be freed and reallocated before
or during the evaluation of q->class and q->logical_mask?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013033430.1885990-2-varun.gupta@intel.com?part=1