From: "Christian König" <christian.koenig@amd.com>
To: Nitin Gote <nitin.r.gote@intel.com>, intel-xe@lists.freedesktop.org
Cc: stable@vger.kernel.org,
Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs
Date: Wed, 1 Jul 2026 10:48:39 +0200 [thread overview]
Message-ID: <613e356a-a88c-4116-b191-455ae3cd6b15@amd.com> (raw)
In-Reply-To: <20260701062559.3731993-2-nitin.r.gote@intel.com>
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;
> }
next prev parent reply other threads:[~2026-07-01 8:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 6:26 [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs Nitin Gote
2026-07-01 5:56 ` ✓ CI.KUnit: success for drm/ttm: Fix UAF on dma-buf attach failure for sg BOs (rev2) Patchwork
2026-07-01 6:46 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-01 8:48 ` Christian König [this message]
2026-07-01 12:59 ` [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs Thomas Hellström
2026-07-01 13:20 ` Christian König
2026-07-01 15:23 ` Thomas Hellström
2026-07-03 10:50 ` Gote, Nitin R
2026-07-01 21:55 ` ✓ Xe.CI.FULL: success for drm/ttm: Fix UAF on dma-buf attach failure for sg BOs (rev2) Patchwork
-- strict thread matches above, loose matches on Subject: below --
2026-06-25 5:57 [PATCH] drm/ttm: Fix UAF on dma-buf attach failure for sg BOs Nitin Gote
2026-06-25 10:45 ` Christian König
2026-06-25 17:10 ` Gote, Nitin R
2026-06-29 12:09 ` Christian König
2026-06-29 9:18 ` Thomas Hellström
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=613e356a-a88c-4116-b191-455ae3cd6b15@amd.com \
--to=christian.koenig@amd.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=nitin.r.gote@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.