Re: [PATCH] drm/xe: Skip clearing purged page-table BOs

[Matthew Brost <matthew.brost@intel.com>]

On Fri, Sep 04, 2026 at 12:40:22PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Incomplete fix: Page-table BOs accessed in `xe_pt_zap_ptes_entry` and `xe_pt_stage_unbind_entry` may be purged, leading to a NULL pointer dereference when accessing their `vmap`.
> --
> 
> commit d85d3cf8e80d3cf9458c1419a52b39bf03260f55
> Author: Tejas Upadhyay <tejas.upadhyay@intel.com>
> 
> drm/xe: Skip clearing purged page-table BOs
> 
> This commit updates xe_pt_clear() to check if a page-table buffer object
> has been purged before writing to its mapping. It acquires the dma-resv
> lock to safely check the purged state and avoid NULL pointer dereferences.
> 
> > diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> > index a07316a45d79b..74a6174aae4e3 100644
> > --- a/drivers/gpu/drm/xe/xe_pt.c
> > +++ b/drivers/gpu/drm/xe/xe_pt.c
> > @@ -236,9 +236,12 @@ void xe_pt_destroy(struct xe_pt *pt, u32 flags, struct llist_head *deferred)
> >   */
> >  void xe_pt_clear(struct xe_device *xe, struct xe_pt *pt)
> >  {
> > -	struct iosys_map *map = &pt->bo->vmap;
> > +	struct xe_bo *bo = pt->bo;
> >  
> > -	xe_map_memset(xe, map, 0, 0, SZ_4K);
> > +	xe_bo_lock(bo, false);
> > +	if (!xe_bo_is_purged(bo))
> > +		xe_map_memset(xe, &bo->vmap, 0, 0, SZ_4K);
> > +	xe_bo_unlock(bo);
> >  }
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but while this successfully
> prevents a NULL pointer dereference here, does the same vulnerability
> still exist in other page-table accessors in drivers/gpu/drm/xe/xe_pt.c?
> 
> For example, in xe_pt_zap_ptes_entry():
> 
> 	xe_map_memset(tile_to_xe(xe_walk->tile), &xe_child->bo->vmap,
> 		      offset * sizeof(u64), 0,
> 		      (end_offset - offset) * sizeof(u64));
>

This probably right but tricky to solve. We really need to do is lock
the entire VM + take the notifier lock to ensure no zaps race + set a flag
to prevent future zaps running on the VM. It will actually get worse too
and we have discussed pipeline zaps in TLB invalidation jobs too.

> If xe_child->bo has been purged by VRAM page offlining, its vmap is cleared
> and xe_map_memset() will dereference a NULL pointer. Since this executes
> without the dma_resv lock, could it be vulnerable to concurrent purges?
> 
> Similarly, in xe_pt_stage_unbind_entry():
> 
> 	pte = xe_map_rd(xe, leaf_map, (first + i) * sizeof(u64), u64);
> 

This isn't possible as we kill the VM under lock before purging a PT BO.
New VM binds can't be issued on a killed VM, thus
xe_pt_stage_unbind_entry is unreachable. What will be problem is
pipelined binds/unbinds, once CPU binds land (WIP) is if we remove the
CPU mapping, plus a few more issue detailed below.

I think both of these are worth documenting in a Jira. Something like
'safe VM kill when purging PT BOs' - I didn't review this part quite
enough but we can fix in a follow up.

Below is roughly the flow I think we need to make PT purging safe:

- Kill every exec queue in VM, including bind queues (future proof for
  CPU binds)
- Kill all TLB invalidation queues on VM (future proof for when we add
  zaps)
- If not root PT, invalidate root PT(s) + zap PTEs (cuts hardware access
  to PTs)
- Lock entire VM + notifier
	- Set flag to prevent future zaps
	- Set the VM killed flag (cuts off uAPI access to VM)
- Purge BO
- All future zaps detect this VM PTs can not longer be tocuhed - flag is
  stable as we always have at 1 of the locks when entire VM + notifier
  is locked

The patch posted here should move forward with the locking fixes I have
suggested in previous reply, as this standalone fix that is also correct
and required.

Matt

> If the BO was previously purged, its vmap is NULL, and reading from it via
> xe_map_rd() will also result in a NULL pointer dereference.
> 
> Can these paths be triggered by unprivileged userspace via standard VM
> unbind ioctls or MMU notifier invalidations?
> 
> >  
> >  /**
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260904122121.806122-2-tejas.upadhyay@intel.com?part=1