Re: [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Wed, 2026-07-01 at 15:20 +0200, Christian König wrote:
> On 7/1/26 14:59, Thomas Hellström wrote:
> > Hi, Nitin
> > 
> > On Wed, 2026-07-01 at 11:56 +0530, Nitin Gote wrote:
> > > When a dma-buf importer creates a ttm_bo_type_sg BO with bo-
> > > > base.resv
> > > pointing at the exporter's dma_buf->resv and
> > > dma_buf_dynamic_attach()
> > > fails, no dma_buf reference is held. The exporter can be freed
> > > before
> > > the delayed_delete worker calls dma_resv_lock(bo->base.resv),
> > > causing
> > > a
> > > use-after-free:
> > > 
> > >   Oops: general protection fault, probably for non-canonical
> > > address
> > >         0x6b6b6b6b6b6b6b9c
> > >   Workqueue: ttm ttm_bo_delayed_delete [ttm]
> > >   RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0
> > > 
> > > ttm_bo_individualize_resv() skips the resv swap for all sg BOs to
> > > keep
> > > the shared resv available for delayed_delete to release the dma-
> > > buf
> > > mapping. A BO whose attach never succeeded has no mapping to
> > > release,
> > > yet it keeps bo->base.resv pointing at the exporter resv that
> > > delayed_delete later locks once the exporter is gone.
> > > 
> > > Fix this by checking bo->base.import_attach, which is set only
> > > after
> > > a
> > > successful attach. The check is placed after
> > > dma_resv_copy_fences()
> > > so
> > > successful imports still copy fences to _resv before returning,
> > > keeping
> > > the shared resv for delayed_delete. Failed imports fall through
> > > to
> > > swap
> > > resv to _resv, so delayed_delete never locks the stale exporter
> > > resv.
> > > 
> > > Closes:
> > > https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8023
> > > Fixes: d99fbd9aab62 ("drm/ttm: Always take the bo delayed cleanup
> > > path for imported bos")
> > > Cc: stable@vger.kernel.org # v6.8+
> > > Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
> > > Cc: Christian Konig <christian.koenig@amd.com>
> > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > Assisted-by: GitHub_Copilot:claude-sonnet-4.6
> > > Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
> > > ---
> > > Hi Thomas/Christian,
> > > Thank you for the review. Addressed the v3 review comments in
> > > this 
> > > v4 version.
> > > 
> > > v4:
> > > - Moved import_attach check to after dma_resv_copy_fences() so
> > > fences
> > >   are copied before returning for successful imports (Thomas).
> > > - Removed exporter-alive claim from commit message (Thomas).
> > 
> > That's not sufficient. What I meant was that this invalidates the
> > approach in its current form:
> > 
> > A			B
> > prime_import()		
> > exported_get();
> > exported_lock();
> > bo_create();		lru_walk():
> > attach_fail();		bo_get();
> > bo_put();		
> > exported_unlock();	bo_lock() // exporter_lock
> > exporter_put();		
> > exporter_free();	
> > 			bo_unlock(); //UAF
> > 			
> > There is no guarantee that the exporter stays alive until
> > resv individualization happens.
> 
> IIRC at least for AMDGPU that shouldn't be possible.
> 
> We intentionally create the imported BO as empty shell without
> ttm_resource object, so it is not on any LRU list.
> 
> But to be honest I haven't looked into that in years, so it is
> perfectly possible that this is messed up again.

Yeah, this was recently changed in xe, but I'm not 100% sure we
actually create a bo resource.

In any case if we add an assert

WARN_ON_ONCE(bo->type == ttm_bo_type_sg && bo->res);

just before / after 
bo->base.resv = &bo->base._resv;

or something similar, we would hit that if the bo is published on the
LRU and would need an additional fix in the driver.

/Thomas


> 
> Regards,
> Christian.
> 
> > 
> > /Thomas
> > 
> > 
> > > 
> > > v3:
> > > - Dropped the xe-side reordering approach since importer_priv
> > > must be
> > >   valid when dma_buf_dynamic_attach() publishes the attachment.
> > > - Per Christian's suggestion on the v1 thread, keyed the check on
> > >   import_attach rather than removing the sg guard entirely.
> > > - Fixes both xe and amdgpu in a single TTM patch.
> > > 
> > >  drivers/gpu/drm/ttm/ttm_bo.c | 24 +++++++++++++++---------
> > >  1 file changed, 15 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index bcd76f6bb7f0..9b6341f69805 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -203,15 +203,21 @@ static int ttm_bo_individualize_resv(struct
> > > ttm_buffer_object *bo)
> > >  	if (r)
> > >  		return r;
> > >  
> > > -	if (bo->type != ttm_bo_type_sg) {
> > > -		/* This works because the BO is about to be
> > > destroyed and nobody
> > > -		 * reference it any more. The only tricky case
> > > is
> > > the trylock on
> > > -		 * the resv object while holding the lru_lock.
> > > -		 */
> > > -		spin_lock(&bo->bdev->lru_lock);
> > > -		bo->base.resv = &bo->base._resv;
> > > -		spin_unlock(&bo->bdev->lru_lock);
> > > -	}
> > > +	/*
> > > +	 * Successfully imported sg BOs need the shared resv for
> > > dma-buf
> > > +	 * cleanup. Failed imports have no attachment or mapping
> > > and
> > > can
> > > +	 * use the private _resv.
> > > +	 */
> > > +	if (bo->type == ttm_bo_type_sg && bo-
> > > >base.import_attach)
> > > +		return 0;
> > > +
> > > +	/* This works because the BO is about to be destroyed
> > > and
> > > nobody
> > > +	 * references it any more. The only tricky case is the
> > > trylock on
> > > +	 * the resv object while holding the lru_lock.
> > > +	 */
> > > +	spin_lock(&bo->bdev->lru_lock);
> > > +	bo->base.resv = &bo->base._resv;
> > > +	spin_unlock(&bo->bdev->lru_lock);
> > >  
> > >  	return r;
> > >  }