Re: [PATCH v4 07/25] drm/xe: Update scheduler job layer to support PT jobs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Type Confusion in xe_sched_job union leads to kernel pointer leak via trace events and devcoredump
--

commit 6a6fd5ea520b6b9671aa39ce12a2edcd42ab0033
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Update scheduler job layer to support PT jobs

This commit updates the scheduler job layer to support page table (PT) jobs,
which run entirely on the CPU. It reuses the LRC fence storage by introducing
a union in the xe_sched_job struct to hold PT update arguments when the job
does not require an LRC fence or batch address.

Link: https://patch.msgid.link/20260228013501.106680-8-matthew.brost@intel.com

> diff --git a/drivers/gpu/drm/xe/xe_sched_job_types.h b/drivers/gpu/drm/xe/xe_sched_job_types.h
> index 0490b1247a6e9..5e1824c36c740 100644
> --- a/drivers/gpu/drm/xe/xe_sched_job_types.h
> +++ b/drivers/gpu/drm/xe/xe_sched_job_types.h

[ ... ]

> @@ -71,8 +90,14 @@ struct xe_sched_job {
>  	bool restore_replay;
>  	/** @last_replay: last job being replayed */
>  	bool last_replay;
> -	/** @ptrs: per instance pointers. */
> -	struct xe_job_ptrs ptrs[];
> +	/** @is_pt_job: is a PT job */
> +	bool is_pt_job;
> +	union {
> +		/** @ptrs: per instance pointers. */
> +		DECLARE_FLEX_ARRAY(struct xe_job_ptrs, ptrs);
> +		/** @pt_update: PT update arguments */
> +		DECLARE_FLEX_ARRAY(struct xe_pt_update_args, pt_update);
> +	};
>  };
>  

[Severity: Medium]
Does this regression cause a kernel pointer leak when the job is a PT job?

In struct xe_job_ptrs, batch_addr is a 64-bit value that aliases with the
const struct xe_migrate_pt_update_ops *ops pointer in struct
xe_pt_update_args.

When xe_sched_job_snapshot_capture() in drivers/gpu/drm/xe/xe_sched_job.c
captures a snapshot, it appears to unconditionally read batch_addr without
checking if the job is a PT job:

for (i = 0; i < q->width; i++)
	snapshot->batch_addr[i] =
		xe_device_uncanonicalize_addr(xe, job->ptrs[i].batch_addr);

Similarly, the xe_sched_job trace event in drivers/gpu/drm/xe/xe_trace.h
unconditionally reads batch_addr:

__entry->batch_addr = (u64)job->ptrs[0].batch_addr;

Can this type confusion expose kernel function pointers to userspace via
trace events or sysfs devcoredump during a GPU hang?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903235842.3401722-1-matthew.brost@intel.com?part=7