Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Nitin Gote <nitin.r.gote@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Nitin Gote <nitin.r.gote@intel.com>,
	stable@vger.kernel.org,
	Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
	Matthew Brost <matthew.brost@intel.com>,
	Matthew Auld <matthew.auld@intel.com>
Subject: [PATCH] drm/xe: Fix UAF in xe_gem_prime_import() on attach failure
Date: Mon,  1 Jun 2026 15:45:37 +0530	[thread overview]
Message-ID: <20260601101536.1333480-2-nitin.r.gote@intel.com> (raw)

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;
 		xe_bo_put(gem_to_xe_bo(obj));
 		return ERR_CAST(attach);
 	}
-- 
2.50.1


             reply	other threads:[~2026-06-01  9:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 10:15 Nitin Gote [this message]
2026-06-01 10:46 ` [PATCH] drm/xe: Fix UAF in xe_gem_prime_import() on attach failure Matthew Auld
2026-06-01 11:39   ` Christian König
2026-06-01 12:01     ` Matthew Auld
2026-06-01 12:17       ` Christian König
2026-06-01 15:27         ` Gote, Nitin R
2026-06-04  4:54           ` Gote, Nitin R
2026-06-04 11:14             ` Thomas Hellström
2026-06-04 11:32               ` Matthew Auld
2026-06-04 11:55                 ` Thomas Hellström
2026-06-05  9:56                 ` Christian König
2026-06-11 13:04                   ` Gote, Nitin R
2026-06-11 14:06                     ` Thomas Hellström
2026-06-05 10:11               ` Christian König
  -- strict thread matches above, loose matches on Subject: below --
2026-06-04 10:23 Nitin Gote

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260601101536.1333480-2-nitin.r.gote@intel.com \
    --to=nitin.r.gote@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=thomas.hellstrom@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox