Re: [PATCH v4 11/25] drm/xe: Store level in struct xe_vm_pgtable_update

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Silent failure during page-table unbind due to unhandled -ENOMEM can lead to GPU Use-After-Free.
--

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

drm/xe: Store level in struct xe_vm_pgtable_update

This commit stores the level directly in struct xe_vm_pgtable_update to
avoid accessing struct xe_pt during bind jobs. This is necessary because
struct xe_pt may no longer be valid in memory when CPU binds are supported
in bind jobs.

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

> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> index 4c277153398e6..486de8a46a6a5 100644
> --- a/drivers/gpu/drm/xe/xe_pt.c
> +++ b/drivers/gpu/drm/xe/xe_pt.c
> @@ -389,6 +389,7 @@ xe_pt_new_shared(struct xe_walk_update *wupd, struct xe_pt *parent,
>  	entry->flags = 0;
>  	entry->qwords = 0;
>  	entry->pt_bo->update_index = -1;
> +	entry->level = parent->level;
>  
>  	if (alloc_entries) {
>  		entry->pt_entries = kmalloc_objs(*entry->pt_entries, XE_PDES);

[Severity: Critical]
This is a pre-existing issue, but can this silent failure during page-table
unbind lead to a GPU use-after-free?

When unbind_op_prepare() calls xe_pt_stage_unbind(), the unbind uses
xe_pt_walk_shared() which eventually calls xe_pt_new_shared() with
alloc_entries=true. If kmalloc_objs() fails here, -ENOMEM is returned up to
xe_pt_walk_shared(), terminating the walk early.

However, xe_pt_stage_unbind() ignores this failure by casting the return
value to (void):

drivers/gpu/drm/xe/xe_pt.c:xe_pt_stage_unbind() {
	...
	(void)xe_pt_walk_shared(&pt->base, pt->level, start, end,
				&xe_walk.base);
	...
}

Because the error is swallowed and a truncated update array is returned, the
unbind only partially unmaps the target VMA. The GPU page table retains valid
mappings to memory that is subsequently freed by the CPU.

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