Re: [PATCH] drm/xe: Fix UAF in xe_gem_prime_import() on attach failure

[Matthew Auld <matthew.auld@intel.com>]

On 01/06/2026 12:39, Christian König wrote:
> 
> 
> On 6/1/26 12:46, Matthew Auld wrote:
>> On 01/06/2026 11:15, Nitin Gote wrote:
>>> xe_dma_buf_create_obj() creates the importer BO with obj->resv
>>> pointing at the exporter's dma_buf->resv. When dma_buf_dynamic_attach()
>>> fails, no dma_buf reference is held so the exporter can be freed
>>> immediately. Since ttm_bo_release() now always defers cleanup for
>>> ttm_bo_type_sg BOs to the TTM workqueue, the worker later calls
>>> dma_resv_lock() on the already-freed exporter resv, causing a UAF.
>>>
>>> Reset obj->resv to the BO's private _resv before calling xe_bo_put()
>>> in the error path. The BO is not yet published (attach failed) and
>>> carries no fences, so the switch is safe.
>>>
>>> Observed with igt@xe_live_ktest@xe_dma_buf_kunit on BMG (QEMU):
>>>
>>>     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
>>>     Call Trace:
>>>      <TASK>
>>>      ? __ww_mutex_lock.constprop.0+0x2dd/0x18e0
>>>      ? ttm_bo_delayed_delete+0x41/0xc0 [ttm]
>>>      ww_mutex_lock+0x3c/0xb0
>>>      ttm_bo_delayed_delete+0x41/0xc0 [ttm]
>>>      process_one_work+0x239/0x740
>>>      worker_thread+0x200/0x3f0
>>>      kthread+0x10d/0x150
>>>      ret_from_fork+0x3bd/0x470
>>>      ret_from_fork_asm+0x1a/0x30
>>>      </TASK>
>>>
>>> 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: Matthew Brost <matthew.brost@intel.com>
>>> Cc: Matthew Auld <matthew.auld@intel.com>
>>> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
>>> ---
>>>    drivers/gpu/drm/xe/xe_dma_buf.c | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
>>> index 8a920e58245c..6d944bd4065c 100644
>>> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
>>> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
>>> @@ -384,6 +384,14 @@ struct drm_gem_object *xe_gem_prime_import(struct drm_device *dev,
>>>          attach = dma_buf_dynamic_attach(dma_buf, dev->dev, attach_ops, obj);
>>>        if (IS_ERR(attach)) {
>>> +        /*
>>> +         * The BO was created with resv = dma_buf->resv (exporter's
>>> +         * resv). Since attach failed, no dma_buf reference is held and
>>> +         * the exporter may be freed before TTM's delayed_delete worker
>>> +         * runs. Switch to the BO's own resv to prevent a UAF when
>>> +         * ttm_bo_delayed_delete() tries to lock the stale pointer.
>>> +         */
>>> +        obj->resv = &obj->_resv;
>>
>> +Christian, does amdgpu not have the type of same issue here? Also any thoughts here?
> 
> Oh, good catch. Yeah I think we have the same problem on amdgpu as well.

Maybe dumb question, but why does the ttm_bo_individualize_resv() skip 
the final switch of the resv for type_sg? It goes through the trouble of 
copying the fences across?

If we do need to handle this here, do we also need to grab the lru lock, 
like we do in ttm_bo_individualize_resv() when doing the swap?

Ideally xe and amdgpu can just have identical solutions here.

> 
> How the heck did you found that? Do we have a dummy driver (VGEM?) which could be made to always fail attachment for a test case?
> 
> @Vitaly can you take a look and try to come up with a test case for that? Thanks in advance.
> 
> Thanks for the notice,
> Christian.
> 
>>
>>>            xe_bo_put(gem_to_xe_bo(obj));
>>>            return ERR_CAST(attach);
>>>        }
>>
>