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

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

[Nitin Gote]

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 only set after
successful dma_buf_dynamic_attach(). Failed imports now individualize
normally, so delayed_delete operates on the BO's private _resv. The
exporter remains alive during individualize as it runs synchronously
in ttm_bo_release(), while the gem_prime_import caller still holds
its dma_buf reference.

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>
---
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.
- Exporter lifetime: individualize runs synchronously inside
  ttm_bo_release(), called from drm_gem_object_put() in the
  gem_prime_import error path while drm_gem_prime_fd_to_handle()
  still holds its dma_buf reference.
- 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..bf8eaec0e9ca 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -196,6 +196,14 @@ static int ttm_bo_individualize_resv(struct ttm_buffer_object *bo)
 	if (bo->base.resv == &bo->base._resv)
 		return 0;
 
+	/*
+	 * 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;
+
 	BUG_ON(!dma_resv_trylock(&bo->base._resv));
 
 	r = dma_resv_copy_fences(&bo->base._resv, bo->base.resv);
@@ -203,15 +211,13 @@ 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);
-	}
+	/* 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;
 }
-- 
2.50.1

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

[Christian König]

On 6/25/26 07:57, 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 only set after
> successful dma_buf_dynamic_attach(). Failed imports now individualize
> normally, so delayed_delete operates on the BO's private _resv. The
> exporter remains alive during individualize as it runs synchronously
> in ttm_bo_release(), while the gem_prime_import caller still holds
> its dma_buf reference.
> 
> 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>
> ---
> 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.
> - Exporter lifetime: individualize runs synchronously inside
>   ttm_bo_release(), called from drm_gem_object_put() in the
>   gem_prime_import error path while drm_gem_prime_fd_to_handle()
>   still holds its dma_buf reference.
> - 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..bf8eaec0e9ca 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -196,6 +196,14 @@ static int ttm_bo_individualize_resv(struct ttm_buffer_object *bo)
>  	if (bo->base.resv == &bo->base._resv)
>  		return 0;
>  
> +	/*
> +	 * 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;
> +

Yeah, that approach looks good to me.

I'm only wondering if some other code than the DMA-buf imports who uses ttm_bo_type_sg could potentially be problematic here. The KFD stuff comes to mind for example.

Maybe ask some AI tool who and how ttm_bo_type_sg is used and double check. I don't think there is a problem, but just to be sure.

Thanks,
Christian.

>  	BUG_ON(!dma_resv_trylock(&bo->base._resv));
>  
>  	r = dma_resv_copy_fences(&bo->base._resv, bo->base.resv);
> @@ -203,15 +211,13 @@ 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);
> -	}
> +	/* 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;
>  }

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

[Gote, Nitin R]

> -----Original Message-----
> From: Christian König <christian.koenig@amd.com>
> Sent: Thursday, June 25, 2026 4:16 PM
> To: Gote, Nitin R <nitin.r.gote@intel.com>; intel-xe@lists.freedesktop.org
> Cc: stable@vger.kernel.org; Thomas Hellstrom
> <thomas.hellstrom@linux.intel.com>; Auld, Matthew <matthew.auld@intel.com>
> Subject: Re: [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs
> 
> On 6/25/26 07:57, 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 only set after
> > successful dma_buf_dynamic_attach(). Failed imports now individualize
> > normally, so delayed_delete operates on the BO's private _resv. The
> > exporter remains alive during individualize as it runs synchronously
> > in ttm_bo_release(), while the gem_prime_import caller still holds its
> > dma_buf reference.
> >
> > 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>
> > ---
> > 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.
> > - Exporter lifetime: individualize runs synchronously inside
> >   ttm_bo_release(), called from drm_gem_object_put() in the
> >   gem_prime_import error path while drm_gem_prime_fd_to_handle()
> >   still holds its dma_buf reference.
> > - 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..bf8eaec0e9ca 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -196,6 +196,14 @@ static int ttm_bo_individualize_resv(struct
> ttm_buffer_object *bo)
> >  	if (bo->base.resv == &bo->base._resv)
> >  		return 0;
> >
> > +	/*
> > +	 * 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;
> > +
> 
> Yeah, that approach looks good to me.
> 
> I'm only wondering if some other code than the DMA-buf imports who uses
> ttm_bo_type_sg could potentially be problematic here. The KFD stuff comes to
> mind for example.
> 
> Maybe ask some AI tool who and how ttm_bo_type_sg is used and double check.
> I don't think there is a problem, but just to be sure.
> 

I went through the other ttm_bo_type_sg users, though I'm not too familiar with the KFD code. Please correct me if I got something wrong.

At KFD create_dmamap_sg_bo(): It creates the sg BO with the parent's resv and never sets import_attach, so with this patch it now individualises. 
That looks fine: the new sg BO holds an amdgpu_bo_ref() on the parent until its own amdgpu_bo_destroy(), so the parent resv is still valid 
while dma_resv_copy_fences() runs (which reads the source under RCU anyway), and with no dma-buf attachment there's nothing that needs the shared
resv at cleanup.

The rest (KFD doorbell/MMIO and amdgpu_gart) create with resv = NULL, so resv already points at _resv and the first check in ttm_bo_individualize_resv()
returns early, so no change there.

Seems like there is no problem in KFD case.

Regards,
Nitin

> Thanks,
> Christian.
> 
> >  	BUG_ON(!dma_resv_trylock(&bo->base._resv));
> >
> >  	r = dma_resv_copy_fences(&bo->base._resv, bo->base.resv); @@ -
> 203,15
> > +211,13 @@ 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);
> > -	}
> > +	/* 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;
> >  }

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

[Thomas Hellström]

On Thu, 2026-06-25 at 11:27 +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 only set after
> successful dma_buf_dynamic_attach(). Failed imports now individualize
> normally, so delayed_delete operates on the BO's private _resv. The
> exporter remains alive during individualize as it runs synchronously
> in ttm_bo_release(), while the gem_prime_import caller still holds
> its dma_buf reference.

I think since the bo is published on the LRU, a LRU walk can still grab
a bo reference before the prime_import caller calls put(). So this
doesn't necessarily hold?

> 
> 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>
> ---
> 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.
> - Exporter lifetime: individualize runs synchronously inside
>   ttm_bo_release(), called from drm_gem_object_put() in the
>   gem_prime_import error path while drm_gem_prime_fd_to_handle()
>   still holds its dma_buf reference.
> - 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..bf8eaec0e9ca 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -196,6 +196,14 @@ static int ttm_bo_individualize_resv(struct
> ttm_buffer_object *bo)
>  	if (bo->base.resv == &bo->base._resv)
>  		return 0;
>  
> +	/*
> +	 * 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;
> +

You would still need to copy the current fences to _resv here, because
otherwise, the object can be premaurely released. It's considered idle
when the fences attached to _resv have all signaled. So this needs to
be moved below the fence duplication below.

Thanks,
Thomas



>  	BUG_ON(!dma_resv_trylock(&bo->base._resv));
>  
>  	r = dma_resv_copy_fences(&bo->base._resv, bo->base.resv);
> @@ -203,15 +211,13 @@ 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);
> -	}
> +	/* 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;
>  }

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

[Christian König]

On 6/25/26 19:10, Gote, Nitin R wrote:
>> -----Original Message-----
>> From: Christian König <christian.koenig@amd.com>
>> Sent: Thursday, June 25, 2026 4:16 PM
>> To: Gote, Nitin R <nitin.r.gote@intel.com>; intel-xe@lists.freedesktop.org
>> Cc: stable@vger.kernel.org; Thomas Hellstrom
>> <thomas.hellstrom@linux.intel.com>; Auld, Matthew <matthew.auld@intel.com>
>> Subject: Re: [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs
>>
>> On 6/25/26 07:57, 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 only set after
>>> successful dma_buf_dynamic_attach(). Failed imports now individualize
>>> normally, so delayed_delete operates on the BO's private _resv. The
>>> exporter remains alive during individualize as it runs synchronously
>>> in ttm_bo_release(), while the gem_prime_import caller still holds its
>>> dma_buf reference.
>>>
>>> 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>
>>> ---
>>> 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.
>>> - Exporter lifetime: individualize runs synchronously inside
>>>   ttm_bo_release(), called from drm_gem_object_put() in the
>>>   gem_prime_import error path while drm_gem_prime_fd_to_handle()
>>>   still holds its dma_buf reference.
>>> - 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..bf8eaec0e9ca 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -196,6 +196,14 @@ static int ttm_bo_individualize_resv(struct
>> ttm_buffer_object *bo)
>>>  	if (bo->base.resv == &bo->base._resv)
>>>  		return 0;
>>>
>>> +	/*
>>> +	 * 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;
>>> +
>>
>> Yeah, that approach looks good to me.
>>
>> I'm only wondering if some other code than the DMA-buf imports who uses
>> ttm_bo_type_sg could potentially be problematic here. The KFD stuff comes to
>> mind for example.
>>
>> Maybe ask some AI tool who and how ttm_bo_type_sg is used and double check.
>> I don't think there is a problem, but just to be sure.
>>
> 
> I went through the other ttm_bo_type_sg users, though I'm not too familiar with the KFD code. Please correct me if I got something wrong.
> 
> At KFD create_dmamap_sg_bo(): It creates the sg BO with the parent's resv and never sets import_attach, so with this patch it now individualises. 
> That looks fine: the new sg BO holds an amdgpu_bo_ref() on the parent until its own amdgpu_bo_destroy(), so the parent resv is still valid 
> while dma_resv_copy_fences() runs (which reads the source under RCU anyway), and with no dma-buf attachment there's nothing that needs the shared
> resv at cleanup.
> 
> The rest (KFD doorbell/MMIO and amdgpu_gart) create with resv = NULL, so resv already points at _resv and the first check in ttm_bo_individualize_resv()
> returns early, so no change there.
> 
> Seems like there is no problem in KFD case.

Sounds good, with the issue mentioned by Thomas fixed I think that this should work.

Please update the patch and send out a new version for review.

Thanks,
Christian.

> 
> Regards,
> Nitin
> 
>> Thanks,
>> Christian.
>>
>>>  	BUG_ON(!dma_resv_trylock(&bo->base._resv));
>>>
>>>  	r = dma_resv_copy_fences(&bo->base._resv, bo->base.resv); @@ -
>> 203,15
>>> +211,13 @@ 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);
>>> -	}
>>> +	/* 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;
>>>  }
> 

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

[Nitin Gote]

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).

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;
 }
-- 
2.50.1

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

[Christian König]

On 7/1/26 08:26, 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>

Reviewed-by: Christian König <christian.koenig@amd.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).
> 
> 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;
>  }

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

[Thomas Hellström]

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.

/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;
>  }

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

[Christian König]

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.

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;
>>  }

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

[Thomas Hellström]

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;
> > >  }

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

[Gote, Nitin R]

> -----Original Message-----
> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Sent: Wednesday, July 1, 2026 8:53 PM
> To: Christian König <christian.koenig@amd.com>; Gote, Nitin R
> <nitin.r.gote@intel.com>; intel-xe@lists.freedesktop.org
> Cc: stable@vger.kernel.org; Auld, Matthew <matthew.auld@intel.com>
> Subject: Re: [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs
> 
> 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.

Thank you Thomas. I checked the xe flow.

xe_dma_buf_create_obj() calls xe_bo_init_locked() with system placement for sg BOs, so the BO gets a ttm_resource and can be placed on the LRU before attach is attempted.
So the race you pointed out looks real for xe.

I'll add the WARN_ON_ONCE() around the resv swap and re-run the test, then work on the xe-side fix based on the result.

Regards,
Nitin

> 
> /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;
> > > >  }