Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>, intel-xe@lists.freedesktop.org
Cc: Matthew Brost <matthew.brost@intel.com>, stable@vger.kernel.org
Subject: Re: [PATCH v2 2/2] drm/xe/dma-buf: fix UAF with retry loop
Date: Thu, 07 May 2026 14:22:22 +0200	[thread overview]
Message-ID: <c434737c3613a2dff0e2442e89c7ec58640efed4.camel@linux.intel.com> (raw)
In-Reply-To: <20260507115519.115309-4-matthew.auld@intel.com>

On Thu, 2026-05-07 at 12:55 +0100, Matthew Auld wrote:
> Retry doesn't work here, since bo will be freed on error, leading to
> UAF. However, now that we do the alloc & init before the attach, we
> can
> now combine this as one unit and have the init do the alloc for us.
> This
> should make the retry safe.
> 
> Reported by Sashiko.
> 
> Closes:
> https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com
> Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive
> eviction")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: <stable@vger.kernel.org> # v6.18+

lgtm.
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>



> ---
>  drivers/gpu/drm/xe/xe_dma_buf.c | 42 +++++++++----------------------
> --
>  1 file changed, 11 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c
> b/drivers/gpu/drm/xe/xe_dma_buf.c
> index 2332db502c8b..a54ec278a915 100644
> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> @@ -258,16 +258,8 @@ struct dma_buf *xe_gem_prime_export(struct
> drm_gem_object *obj, int flags)
>  	return ERR_PTR(ret);
>  }
>  
> -/*
> - * Takes ownership of @storage: on success it is transferred to the
> returned
> - * drm_gem_object; on failure it is freed before returning the
> error.
> - * This matches the contract of xe_bo_init_locked() which frees
> @storage on
> - * its error paths, so callers need not (and must not) free @storage
> after
> - * this call.
> - */
>  static struct drm_gem_object *
> -xe_dma_buf_init_obj(struct drm_device *dev, struct xe_bo *storage,
> -		    struct dma_buf *dma_buf)
> +xe_dma_buf_create_obj(struct drm_device *dev, struct dma_buf
> *dma_buf)
>  {
>  	struct dma_resv *resv = dma_buf->resv;
>  	struct xe_device *xe = to_xe_device(dev);
> @@ -278,10 +270,8 @@ xe_dma_buf_init_obj(struct drm_device *dev,
> struct xe_bo *storage,
>  	int ret = 0;
>  
>  	dummy_obj = drm_gpuvm_resv_object_alloc(&xe->drm);
> -	if (!dummy_obj) {
> -		xe_bo_free(storage);
> +	if (!dummy_obj)
>  		return ERR_PTR(-ENOMEM);
> -	}
>  
>  	dummy_obj->resv = resv;
>  	xe_validation_guard(&ctx, &xe->val, &exec, (struct
> xe_val_flags) {}, ret) {
> @@ -290,8 +280,7 @@ xe_dma_buf_init_obj(struct drm_device *dev,
> struct xe_bo *storage,
>  		if (ret)
>  			break;
>  
> -		/* xe_bo_init_locked() frees storage on error */
> -		bo = xe_bo_init_locked(xe, storage, NULL, resv,
> NULL, dma_buf->size,
> +		bo = xe_bo_init_locked(xe, NULL, NULL, resv, NULL,
> dma_buf->size,
>  				       0, /* Will require 1way or
> 2way for vm_bind */
>  				       ttm_bo_type_sg,
> XE_BO_FLAG_SYSTEM, &exec);
>  		drm_exec_retry_on_contention(&exec);
> @@ -342,7 +331,6 @@ struct drm_gem_object *xe_gem_prime_import(struct
> drm_device *dev,
>  	const struct dma_buf_attach_ops *attach_ops;
>  	struct dma_buf_attachment *attach;
>  	struct drm_gem_object *obj;
> -	struct xe_bo *bo;
>  
>  	if (dma_buf->ops == &xe_dmabuf_ops) {
>  		obj = dma_buf->priv;
> @@ -357,22 +345,14 @@ struct drm_gem_object
> *xe_gem_prime_import(struct drm_device *dev,
>  		}
>  	}
>  
> -	bo = xe_bo_alloc();
> -	if (IS_ERR(bo))
> -		return ERR_CAST(bo);
> -
>  	/*
> -	 * xe_dma_buf_init_obj() takes ownership of the raw bo, so
> do not touch
> -	 * on fail, since it will already take care of cleanup. On
> success we
> -	 * still need to drop the ref, if something later fails.
> -	 *
> -	 * In addition this needs to happen before the attach, since
> -	 * it will create a new attachment for this, and add it to
> the list of
> -	 * attachments, at which point it is globally visible, and
> at any point
> -	 * the export side can call into on invalidate_mappings
> callback, which
> -	 * require a working object.
> +	 * This needs to happen before the attach, since it will
> create a new
> +	 * attachment for this, and add it to the list of
> attachments, at which
> +	 * point it is globally visible, and at any point the export
> side can
> +	 * call into on invalidate_mappings callback, which require
> a working
> +	 * object.
>  	 */
> -	obj = xe_dma_buf_init_obj(dev, bo, dma_buf);
> +	obj = xe_dma_buf_create_obj(dev, dma_buf);

Cant you just use xe_bo_create_novm() here?


>  	if (IS_ERR(obj))
>  		return obj;
>  
> @@ -382,7 +362,7 @@ struct drm_gem_object *xe_gem_prime_import(struct
> drm_device *dev,
>  		attach_ops = test->attach_ops;
>  #endif
>  
> -	attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
> attach_ops, &bo->ttm.base);
> +	attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
> attach_ops, obj);
>  	if (IS_ERR(attach)) {
>  		obj = ERR_CAST(attach);
>  		goto out_err;
> @@ -393,7 +373,7 @@ struct drm_gem_object *xe_gem_prime_import(struct
> drm_device *dev,
>  	return obj;
>  
>  out_err:
> -	xe_bo_put(bo);
> +	xe_bo_put(gem_to_xe_bo(obj));
>  
>  	return obj;
>  }

  reply	other threads:[~2026-05-07 12:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-07 11:55 [PATCH v2 1/2] drm/xe/dma-buf: handle empty bo and UAF races Matthew Auld
2026-05-07 11:55 ` [PATCH v2 2/2] drm/xe/dma-buf: fix UAF with retry loop Matthew Auld
2026-05-07 12:22   ` Thomas Hellström [this message]
2026-05-07 12:35     ` Matthew Auld

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=c434737c3613a2dff0e2442e89c7ec58640efed4.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=stable@vger.kernel.org \
    /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