[Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Rob Clark]

From: Rob Clark <robdclark@chromium.org>

gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this.  And we
need to ensure that adding the ctx to the xarray is the *last* thing
that gem_context_register() does with the ctx pointer.

Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7f2831efc798..6250de9b9196 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
 	init_contexts(&i915->gem.contexts);
 }
 
+/*
+ * Note that this implicitly consumes the ctx reference, by placing
+ * the ctx in the context_xa.
+ */
 static void gem_context_register(struct i915_gem_context *ctx,
 				 struct drm_i915_file_private *fpriv,
 				 u32 id)
@@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
 	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
 		 current->comm, pid_nr(ctx->pid));
 
-	/* And finally expose ourselves to userspace via the idr */
-	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
-	WARN_ON(old);
-
 	spin_lock(&ctx->client->ctx_lock);
 	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
 	spin_unlock(&ctx->client->ctx_lock);
@@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
 	spin_lock(&i915->gem.contexts.lock);
 	list_add_tail(&ctx->link, &i915->gem.contexts.list);
 	spin_unlock(&i915->gem.contexts.lock);
+
+	/* And finally expose ourselves to userspace via the idr */
+	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
+	WARN_ON(old);
 }
 
 int i915_gem_context_open(struct drm_i915_private *i915,
@@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
 	if (IS_ERR(ctx))
 		return ctx;
 
+	/*
+	 * One for the xarray and one for the caller.  We need to grab
+	 * the reference *prior* to making the ctx visble to userspace
+	 * in gem_context_register(), as at any point after that
+	 * userspace can try to race us with another thread destroying
+	 * the context under our feet.
+	 */
+	i915_gem_context_get(ctx);
+
 	gem_context_register(ctx, file_priv, id);
 
 	old = xa_erase(&file_priv->proto_context_xa, id);
 	GEM_BUG_ON(old != pc);
 	proto_context_close(file_priv->dev_priv, pc);
 
-	/* One for the xarray and one for the caller */
-	return i915_gem_context_get(ctx);
+	return ctx;
 }
 
 struct i915_gem_context *
-- 
2.38.1

[PATCH] drm/i915: Fix potential context UAFs

[Rob Clark]

From: Rob Clark <robdclark@chromium.org>

gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this.  And we
need to ensure that adding the ctx to the xarray is the *last* thing
that gem_context_register() does with the ctx pointer.

Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7f2831efc798..6250de9b9196 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
 	init_contexts(&i915->gem.contexts);
 }
 
+/*
+ * Note that this implicitly consumes the ctx reference, by placing
+ * the ctx in the context_xa.
+ */
 static void gem_context_register(struct i915_gem_context *ctx,
 				 struct drm_i915_file_private *fpriv,
 				 u32 id)
@@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
 	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
 		 current->comm, pid_nr(ctx->pid));
 
-	/* And finally expose ourselves to userspace via the idr */
-	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
-	WARN_ON(old);
-
 	spin_lock(&ctx->client->ctx_lock);
 	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
 	spin_unlock(&ctx->client->ctx_lock);
@@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
 	spin_lock(&i915->gem.contexts.lock);
 	list_add_tail(&ctx->link, &i915->gem.contexts.list);
 	spin_unlock(&i915->gem.contexts.lock);
+
+	/* And finally expose ourselves to userspace via the idr */
+	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
+	WARN_ON(old);
 }
 
 int i915_gem_context_open(struct drm_i915_private *i915,
@@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
 	if (IS_ERR(ctx))
 		return ctx;
 
+	/*
+	 * One for the xarray and one for the caller.  We need to grab
+	 * the reference *prior* to making the ctx visble to userspace
+	 * in gem_context_register(), as at any point after that
+	 * userspace can try to race us with another thread destroying
+	 * the context under our feet.
+	 */
+	i915_gem_context_get(ctx);
+
 	gem_context_register(ctx, file_priv, id);
 
 	old = xa_erase(&file_priv->proto_context_xa, id);
 	GEM_BUG_ON(old != pc);
 	proto_context_close(file_priv->dev_priv, pc);
 
-	/* One for the xarray and one for the caller */
-	return i915_gem_context_get(ctx);
+	return ctx;
 }
 
 struct i915_gem_context *
-- 
2.38.1

[PATCH] drm/i915: Fix potential context UAFs

[Rob Clark]

From: Rob Clark <robdclark@chromium.org>

gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this.  And we
need to ensure that adding the ctx to the xarray is the *last* thing
that gem_context_register() does with the ctx pointer.

Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7f2831efc798..6250de9b9196 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
 	init_contexts(&i915->gem.contexts);
 }
 
+/*
+ * Note that this implicitly consumes the ctx reference, by placing
+ * the ctx in the context_xa.
+ */
 static void gem_context_register(struct i915_gem_context *ctx,
 				 struct drm_i915_file_private *fpriv,
 				 u32 id)
@@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
 	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
 		 current->comm, pid_nr(ctx->pid));
 
-	/* And finally expose ourselves to userspace via the idr */
-	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
-	WARN_ON(old);
-
 	spin_lock(&ctx->client->ctx_lock);
 	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
 	spin_unlock(&ctx->client->ctx_lock);
@@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
 	spin_lock(&i915->gem.contexts.lock);
 	list_add_tail(&ctx->link, &i915->gem.contexts.list);
 	spin_unlock(&i915->gem.contexts.lock);
+
+	/* And finally expose ourselves to userspace via the idr */
+	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
+	WARN_ON(old);
 }
 
 int i915_gem_context_open(struct drm_i915_private *i915,
@@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
 	if (IS_ERR(ctx))
 		return ctx;
 
+	/*
+	 * One for the xarray and one for the caller.  We need to grab
+	 * the reference *prior* to making the ctx visble to userspace
+	 * in gem_context_register(), as at any point after that
+	 * userspace can try to race us with another thread destroying
+	 * the context under our feet.
+	 */
+	i915_gem_context_get(ctx);
+
 	gem_context_register(ctx, file_priv, id);
 
 	old = xa_erase(&file_priv->proto_context_xa, id);
 	GEM_BUG_ON(old != pc);
 	proto_context_close(file_priv->dev_priv, pc);
 
-	/* One for the xarray and one for the caller */
-	return i915_gem_context_get(ctx);
+	return ctx;
 }
 
 struct i915_gem_context *
-- 
2.38.1

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 03/01/2023 23:49, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> gem_context_register() makes the context visible to userspace, and which
> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> So we need to ensure that nothing uses the ctx ptr after this.  And we
> need to ensure that adding the ctx to the xarray is the *last* thing
> that gem_context_register() does with the ctx pointer.

Any backtraces from oopses or notes on how it was found to record in the commit message?

> Signed-off-by: Rob Clark <robdclark@chromium.org>

Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
References: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace")
Cc: <stable@vger.kernel.org> # v5.15+

> ---
>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>   1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7f2831efc798..6250de9b9196 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>   	init_contexts(&i915->gem.contexts);
>   }
>   
> +/*
> + * Note that this implicitly consumes the ctx reference, by placing
> + * the ctx in the context_xa.
> + */
>   static void gem_context_register(struct i915_gem_context *ctx,
>   				 struct drm_i915_file_private *fpriv,
>   				 u32 id)
> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>   	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>   		 current->comm, pid_nr(ctx->pid));
>   
> -	/* And finally expose ourselves to userspace via the idr */
> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> -	WARN_ON(old);
> -
>   	spin_lock(&ctx->client->ctx_lock);
>   	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>   	spin_unlock(&ctx->client->ctx_lock);
> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>   	spin_lock(&i915->gem.contexts.lock);
>   	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>   	spin_unlock(&i915->gem.contexts.lock);
> +
> +	/* And finally expose ourselves to userspace via the idr */
> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> +	WARN_ON(old);

Have you seen that this hunk is needed or just moving it for a good measure? To be clear, it is probably best to move it even if the current placement cannot cause any problems, I am just double-checking if you had any concrete observations here while mulling over easier stable backports if we would omit it.

>   }
>   
>   int i915_gem_context_open(struct drm_i915_private *i915,
> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>   	if (IS_ERR(ctx))
>   		return ctx;
>   
> +	/*
> +	 * One for the xarray and one for the caller.  We need to grab
> +	 * the reference *prior* to making the ctx visble to userspace
> +	 * in gem_context_register(), as at any point after that
> +	 * userspace can try to race us with another thread destroying
> +	 * the context under our feet.
> +	 */
> +	i915_gem_context_get(ctx);
> +
>   	gem_context_register(ctx, file_priv, id);
>   
>   	old = xa_erase(&file_priv->proto_context_xa, id);
>   	GEM_BUG_ON(old != pc);
>   	proto_context_close(file_priv->dev_priv, pc);
>   
> -	/* One for the xarray and one for the caller */
> -	return i915_gem_context_get(ctx);
> +	return ctx;

Otherwise userspace can look up a context which hasn't had it's reference count increased yep. I can add the Fixes: and Stable: tags while merging if no complaints.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

>   }
>   
>   struct i915_gem_context *

Re: [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 03/01/2023 23:49, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> gem_context_register() makes the context visible to userspace, and which
> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> So we need to ensure that nothing uses the ctx ptr after this.  And we
> need to ensure that adding the ctx to the xarray is the *last* thing
> that gem_context_register() does with the ctx pointer.

Any backtraces from oopses or notes on how it was found to record in the commit message?

> Signed-off-by: Rob Clark <robdclark@chromium.org>

Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
References: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace")
Cc: <stable@vger.kernel.org> # v5.15+

> ---
>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>   1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7f2831efc798..6250de9b9196 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>   	init_contexts(&i915->gem.contexts);
>   }
>   
> +/*
> + * Note that this implicitly consumes the ctx reference, by placing
> + * the ctx in the context_xa.
> + */
>   static void gem_context_register(struct i915_gem_context *ctx,
>   				 struct drm_i915_file_private *fpriv,
>   				 u32 id)
> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>   	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>   		 current->comm, pid_nr(ctx->pid));
>   
> -	/* And finally expose ourselves to userspace via the idr */
> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> -	WARN_ON(old);
> -
>   	spin_lock(&ctx->client->ctx_lock);
>   	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>   	spin_unlock(&ctx->client->ctx_lock);
> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>   	spin_lock(&i915->gem.contexts.lock);
>   	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>   	spin_unlock(&i915->gem.contexts.lock);
> +
> +	/* And finally expose ourselves to userspace via the idr */
> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> +	WARN_ON(old);

Have you seen that this hunk is needed or just moving it for a good measure? To be clear, it is probably best to move it even if the current placement cannot cause any problems, I am just double-checking if you had any concrete observations here while mulling over easier stable backports if we would omit it.

>   }
>   
>   int i915_gem_context_open(struct drm_i915_private *i915,
> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>   	if (IS_ERR(ctx))
>   		return ctx;
>   
> +	/*
> +	 * One for the xarray and one for the caller.  We need to grab
> +	 * the reference *prior* to making the ctx visble to userspace
> +	 * in gem_context_register(), as at any point after that
> +	 * userspace can try to race us with another thread destroying
> +	 * the context under our feet.
> +	 */
> +	i915_gem_context_get(ctx);
> +
>   	gem_context_register(ctx, file_priv, id);
>   
>   	old = xa_erase(&file_priv->proto_context_xa, id);
>   	GEM_BUG_ON(old != pc);
>   	proto_context_close(file_priv->dev_priv, pc);
>   
> -	/* One for the xarray and one for the caller */
> -	return i915_gem_context_get(ctx);
> +	return ctx;

Otherwise userspace can look up a context which hasn't had it's reference count increased yep. I can add the Fixes: and Stable: tags while merging if no complaints.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

>   }
>   
>   struct i915_gem_context *

Re: [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 03/01/2023 23:49, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> gem_context_register() makes the context visible to userspace, and which
> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> So we need to ensure that nothing uses the ctx ptr after this.  And we
> need to ensure that adding the ctx to the xarray is the *last* thing
> that gem_context_register() does with the ctx pointer.

Any backtraces from oopses or notes on how it was found to record in the commit message?

> Signed-off-by: Rob Clark <robdclark@chromium.org>

Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
References: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace")
Cc: <stable@vger.kernel.org> # v5.15+

> ---
>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>   1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7f2831efc798..6250de9b9196 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>   	init_contexts(&i915->gem.contexts);
>   }
>   
> +/*
> + * Note that this implicitly consumes the ctx reference, by placing
> + * the ctx in the context_xa.
> + */
>   static void gem_context_register(struct i915_gem_context *ctx,
>   				 struct drm_i915_file_private *fpriv,
>   				 u32 id)
> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>   	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>   		 current->comm, pid_nr(ctx->pid));
>   
> -	/* And finally expose ourselves to userspace via the idr */
> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> -	WARN_ON(old);
> -
>   	spin_lock(&ctx->client->ctx_lock);
>   	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>   	spin_unlock(&ctx->client->ctx_lock);
> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>   	spin_lock(&i915->gem.contexts.lock);
>   	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>   	spin_unlock(&i915->gem.contexts.lock);
> +
> +	/* And finally expose ourselves to userspace via the idr */
> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> +	WARN_ON(old);

Have you seen that this hunk is needed or just moving it for a good measure? To be clear, it is probably best to move it even if the current placement cannot cause any problems, I am just double-checking if you had any concrete observations here while mulling over easier stable backports if we would omit it.

>   }
>   
>   int i915_gem_context_open(struct drm_i915_private *i915,
> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>   	if (IS_ERR(ctx))
>   		return ctx;
>   
> +	/*
> +	 * One for the xarray and one for the caller.  We need to grab
> +	 * the reference *prior* to making the ctx visble to userspace
> +	 * in gem_context_register(), as at any point after that
> +	 * userspace can try to race us with another thread destroying
> +	 * the context under our feet.
> +	 */
> +	i915_gem_context_get(ctx);
> +
>   	gem_context_register(ctx, file_priv, id);
>   
>   	old = xa_erase(&file_priv->proto_context_xa, id);
>   	GEM_BUG_ON(old != pc);
>   	proto_context_close(file_priv->dev_priv, pc);
>   
> -	/* One for the xarray and one for the caller */
> -	return i915_gem_context_get(ctx);
> +	return ctx;

Otherwise userspace can look up a context which hasn't had it's reference count increased yep. I can add the Fixes: and Stable: tags while merging if no complaints.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

>   }
>   
>   struct i915_gem_context *

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix potential context UAFs

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 8732 bytes --]

== Series Details ==

Series: drm/i915: Fix potential context UAFs
URL   : https://patchwork.freedesktop.org/series/112383/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12541 -> Patchwork_112383v1
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_112383v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_112383v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/index.html

Participating hosts (42 -> 41)
------------------------------

  Additional (1): fi-rkl-11600 
  Missing    (2): bat-dg2-oem1 bat-atsm-1 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_112383v1:

### IGT changes ###

#### Possible regressions ####

  * igt@debugfs_test@read_all_entries:
    - fi-icl-u2:          [PASS][1] -> [ABORT][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/fi-icl-u2/igt@debugfs_test@read_all_entries.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-icl-u2/igt@debugfs_test@read_all_entries.html

  
Known issues
------------

  Here are the changes found in Patchwork_112383v1 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@debugfs_test@basic-hwmon:
    - fi-rkl-11600:       NOTRUN -> [SKIP][3] ([i915#7456])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@debugfs_test@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
    - fi-rkl-11600:       NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@basic:
    - fi-rkl-11600:       NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@gem_lmem_swapping@basic.html

  * igt@gem_tiled_pread_basic:
    - fi-rkl-11600:       NOTRUN -> [SKIP][6] ([i915#3282])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
    - fi-rkl-11600:       NOTRUN -> [SKIP][7] ([i915#7561])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@i915_pm_backlight@basic-brightness.html

  * igt@i915_suspend@basic-s3-without-i915:
    - fi-rkl-11600:       NOTRUN -> [INCOMPLETE][8] ([i915#4817])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - bat-dg1-6:          NOTRUN -> [SKIP][9] ([fdo#111827])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/bat-dg1-6/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-edid-read:
    - fi-rkl-11600:       NOTRUN -> [SKIP][10] ([fdo#111827]) +7 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_chamelium@hdmi-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
    - fi-rkl-11600:       NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_cursor_legacy@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
    - fi-rkl-11600:       NOTRUN -> [SKIP][12] ([fdo#109285] / [i915#4098])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_force_connector_basic@force-load-detect.html

  * igt@kms_psr@primary_page_flip:
    - fi-rkl-11600:       NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
    - fi-rkl-11600:       NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@kms_setmode@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
    - fi-rkl-11600:       NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] / [i915#3708]) +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@prime_vgem@basic-read.html

  * igt@prime_vgem@basic-userptr:
    - fi-rkl-11600:       NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] / [i915#3708])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-rkl-11600/igt@prime_vgem@basic-userptr.html

  * igt@runner@aborted:
    - fi-icl-u2:          NOTRUN -> [FAIL][17] ([i915#4312])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/fi-icl-u2/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@hangcheck:
    - bat-dg1-6:          [INCOMPLETE][18] -> [PASS][19]
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-dg1-6/igt@i915_selftest@live@hangcheck.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/bat-dg1-6/igt@i915_selftest@live@hangcheck.html

  * igt@i915_selftest@live@slpc:
    - bat-adlp-4:         [DMESG-FAIL][20] ([i915#6367]) -> [PASS][21]
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-adlp-4/igt@i915_selftest@live@slpc.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/bat-adlp-4/igt@i915_selftest@live@slpc.html
    - {bat-rpls-1}:       [DMESG-FAIL][22] ([i915#6367]) -> [PASS][23]
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-rpls-1/igt@i915_selftest@live@slpc.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/bat-rpls-1/igt@i915_selftest@live@slpc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-1:
    - {bat-adlp-9}:       [DMESG-WARN][24] ([i915#2867]) -> [PASS][25]
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12541/bat-adlp-9/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-1.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/bat-adlp-9/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
  [i915#7336]: https://gitlab.freedesktop.org/drm/intel/issues/7336
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561


Build changes
-------------

  * Linux: CI_DRM_12541 -> Patchwork_112383v1

  CI-20190529: 20190529
  CI_DRM_12541: b832866fa6063614b3637598aca19aee3bc3039f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7106: 8cce332bdc50d2b20d553d7a0221737f4399d031 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112383v1: b832866fa6063614b3637598aca19aee3bc3039f @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

23dcf6f3aabb drm/i915: Fix potential context UAFs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v1/index.html

[-- Attachment #2: Type: text/html, Size: 9848 bytes --]

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Rob Clark]

On Wed, Jan 4, 2023 at 1:34 AM Tvrtko Ursulin
<tvrtko.ursulin@linux.intel.com> wrote:
>
>
> On 03/01/2023 23:49, Rob Clark wrote:
> > From: Rob Clark <robdclark@chromium.org>
> >
> > gem_context_register() makes the context visible to userspace, and which
> > point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> > So we need to ensure that nothing uses the ctx ptr after this.  And we
> > need to ensure that adding the ctx to the xarray is the *last* thing
> > that gem_context_register() does with the ctx pointer.
>
> Any backtraces from oopses or notes on how it was found to record in the commit message?

It was a UAF bug that was reported to us

https://bugs.chromium.org/p/chromium/issues/detail?id=1401594 (but I
guess security bugs are not going to be visible)

>
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
>
> Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
> References: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace")
> Cc: <stable@vger.kernel.org> # v5.15+
>
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
> >   1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 7f2831efc798..6250de9b9196 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
> >       init_contexts(&i915->gem.contexts);
> >   }
> >
> > +/*
> > + * Note that this implicitly consumes the ctx reference, by placing
> > + * the ctx in the context_xa.
> > + */
> >   static void gem_context_register(struct i915_gem_context *ctx,
> >                                struct drm_i915_file_private *fpriv,
> >                                u32 id)
> > @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
> >       snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
> >                current->comm, pid_nr(ctx->pid));
> >
> > -     /* And finally expose ourselves to userspace via the idr */
> > -     old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> > -     WARN_ON(old);
> > -
> >       spin_lock(&ctx->client->ctx_lock);
> >       list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
> >       spin_unlock(&ctx->client->ctx_lock);
> > @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
> >       spin_lock(&i915->gem.contexts.lock);
> >       list_add_tail(&ctx->link, &i915->gem.contexts.list);
> >       spin_unlock(&i915->gem.contexts.lock);
> > +
> > +     /* And finally expose ourselves to userspace via the idr */
> > +     old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> > +     WARN_ON(old);
>
> Have you seen that this hunk is needed or just moving it for a good measure? To be clear, it is probably best to move it even if the current placement cannot cause any problems, I am just double-checking if you had any concrete observations here while mulling over easier stable backports if we would omit it.
>

This was actually the originally reported issue, the
finalize_create_context_locked() part was something I found when the
original report prompted me to audit gem_context_register() call
paths.


> >   }
> >
> >   int i915_gem_context_open(struct drm_i915_private *i915,
> > @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
> >       if (IS_ERR(ctx))
> >               return ctx;
> >
> > +     /*
> > +      * One for the xarray and one for the caller.  We need to grab
> > +      * the reference *prior* to making the ctx visble to userspace
> > +      * in gem_context_register(), as at any point after that
> > +      * userspace can try to race us with another thread destroying
> > +      * the context under our feet.
> > +      */
> > +     i915_gem_context_get(ctx);
> > +
> >       gem_context_register(ctx, file_priv, id);
> >
> >       old = xa_erase(&file_priv->proto_context_xa, id);
> >       GEM_BUG_ON(old != pc);
> >       proto_context_close(file_priv->dev_priv, pc);
> >
> > -     /* One for the xarray and one for the caller */
> > -     return i915_gem_context_get(ctx);
> > +     return ctx;
>
> Otherwise userspace can look up a context which hasn't had it's reference count increased yep. I can add the Fixes: and Stable: tags while merging if no complaints.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Thanks

BR,
-R

>
> Regards,
>
> Tvrtko
>
> >   }
> >
> >   struct i915_gem_context *

Re: [PATCH] drm/i915: Fix potential context UAFs

[Rob Clark]

On Wed, Jan 4, 2023 at 1:34 AM Tvrtko Ursulin
<tvrtko.ursulin@linux.intel.com> wrote:
>
>
> On 03/01/2023 23:49, Rob Clark wrote:
> > From: Rob Clark <robdclark@chromium.org>
> >
> > gem_context_register() makes the context visible to userspace, and which
> > point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> > So we need to ensure that nothing uses the ctx ptr after this.  And we
> > need to ensure that adding the ctx to the xarray is the *last* thing
> > that gem_context_register() does with the ctx pointer.
>
> Any backtraces from oopses or notes on how it was found to record in the commit message?

It was a UAF bug that was reported to us

https://bugs.chromium.org/p/chromium/issues/detail?id=1401594 (but I
guess security bugs are not going to be visible)

>
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
>
> Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
> References: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace")
> Cc: <stable@vger.kernel.org> # v5.15+
>
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
> >   1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 7f2831efc798..6250de9b9196 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
> >       init_contexts(&i915->gem.contexts);
> >   }
> >
> > +/*
> > + * Note that this implicitly consumes the ctx reference, by placing
> > + * the ctx in the context_xa.
> > + */
> >   static void gem_context_register(struct i915_gem_context *ctx,
> >                                struct drm_i915_file_private *fpriv,
> >                                u32 id)
> > @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
> >       snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
> >                current->comm, pid_nr(ctx->pid));
> >
> > -     /* And finally expose ourselves to userspace via the idr */
> > -     old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> > -     WARN_ON(old);
> > -
> >       spin_lock(&ctx->client->ctx_lock);
> >       list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
> >       spin_unlock(&ctx->client->ctx_lock);
> > @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
> >       spin_lock(&i915->gem.contexts.lock);
> >       list_add_tail(&ctx->link, &i915->gem.contexts.list);
> >       spin_unlock(&i915->gem.contexts.lock);
> > +
> > +     /* And finally expose ourselves to userspace via the idr */
> > +     old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> > +     WARN_ON(old);
>
> Have you seen that this hunk is needed or just moving it for a good measure? To be clear, it is probably best to move it even if the current placement cannot cause any problems, I am just double-checking if you had any concrete observations here while mulling over easier stable backports if we would omit it.
>

This was actually the originally reported issue, the
finalize_create_context_locked() part was something I found when the
original report prompted me to audit gem_context_register() call
paths.


> >   }
> >
> >   int i915_gem_context_open(struct drm_i915_private *i915,
> > @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
> >       if (IS_ERR(ctx))
> >               return ctx;
> >
> > +     /*
> > +      * One for the xarray and one for the caller.  We need to grab
> > +      * the reference *prior* to making the ctx visble to userspace
> > +      * in gem_context_register(), as at any point after that
> > +      * userspace can try to race us with another thread destroying
> > +      * the context under our feet.
> > +      */
> > +     i915_gem_context_get(ctx);
> > +
> >       gem_context_register(ctx, file_priv, id);
> >
> >       old = xa_erase(&file_priv->proto_context_xa, id);
> >       GEM_BUG_ON(old != pc);
> >       proto_context_close(file_priv->dev_priv, pc);
> >
> > -     /* One for the xarray and one for the caller */
> > -     return i915_gem_context_get(ctx);
> > +     return ctx;
>
> Otherwise userspace can look up a context which hasn't had it's reference count increased yep. I can add the Fixes: and Stable: tags while merging if no complaints.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Thanks

BR,
-R

>
> Regards,
>
> Tvrtko
>
> >   }
> >
> >   struct i915_gem_context *

Re: [PATCH] drm/i915: Fix potential context UAFs

[Rob Clark]

On Wed, Jan 4, 2023 at 1:34 AM Tvrtko Ursulin
<tvrtko.ursulin@linux.intel.com> wrote:
>
>
> On 03/01/2023 23:49, Rob Clark wrote:
> > From: Rob Clark <robdclark@chromium.org>
> >
> > gem_context_register() makes the context visible to userspace, and which
> > point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> > So we need to ensure that nothing uses the ctx ptr after this.  And we
> > need to ensure that adding the ctx to the xarray is the *last* thing
> > that gem_context_register() does with the ctx pointer.
>
> Any backtraces from oopses or notes on how it was found to record in the commit message?

It was a UAF bug that was reported to us

https://bugs.chromium.org/p/chromium/issues/detail?id=1401594 (but I
guess security bugs are not going to be visible)

>
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
>
> Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
> References: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace")
> Cc: <stable@vger.kernel.org> # v5.15+
>
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
> >   1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 7f2831efc798..6250de9b9196 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
> >       init_contexts(&i915->gem.contexts);
> >   }
> >
> > +/*
> > + * Note that this implicitly consumes the ctx reference, by placing
> > + * the ctx in the context_xa.
> > + */
> >   static void gem_context_register(struct i915_gem_context *ctx,
> >                                struct drm_i915_file_private *fpriv,
> >                                u32 id)
> > @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
> >       snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
> >                current->comm, pid_nr(ctx->pid));
> >
> > -     /* And finally expose ourselves to userspace via the idr */
> > -     old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> > -     WARN_ON(old);
> > -
> >       spin_lock(&ctx->client->ctx_lock);
> >       list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
> >       spin_unlock(&ctx->client->ctx_lock);
> > @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
> >       spin_lock(&i915->gem.contexts.lock);
> >       list_add_tail(&ctx->link, &i915->gem.contexts.list);
> >       spin_unlock(&i915->gem.contexts.lock);
> > +
> > +     /* And finally expose ourselves to userspace via the idr */
> > +     old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> > +     WARN_ON(old);
>
> Have you seen that this hunk is needed or just moving it for a good measure? To be clear, it is probably best to move it even if the current placement cannot cause any problems, I am just double-checking if you had any concrete observations here while mulling over easier stable backports if we would omit it.
>

This was actually the originally reported issue, the
finalize_create_context_locked() part was something I found when the
original report prompted me to audit gem_context_register() call
paths.


> >   }
> >
> >   int i915_gem_context_open(struct drm_i915_private *i915,
> > @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
> >       if (IS_ERR(ctx))
> >               return ctx;
> >
> > +     /*
> > +      * One for the xarray and one for the caller.  We need to grab
> > +      * the reference *prior* to making the ctx visble to userspace
> > +      * in gem_context_register(), as at any point after that
> > +      * userspace can try to race us with another thread destroying
> > +      * the context under our feet.
> > +      */
> > +     i915_gem_context_get(ctx);
> > +
> >       gem_context_register(ctx, file_priv, id);
> >
> >       old = xa_erase(&file_priv->proto_context_xa, id);
> >       GEM_BUG_ON(old != pc);
> >       proto_context_close(file_priv->dev_priv, pc);
> >
> > -     /* One for the xarray and one for the caller */
> > -     return i915_gem_context_get(ctx);
> > +     return ctx;
>
> Otherwise userspace can look up a context which hasn't had it's reference count increased yep. I can add the Fixes: and Stable: tags while merging if no complaints.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Thanks

BR,
-R

>
> Regards,
>
> Tvrtko
>
> >   }
> >
> >   struct i915_gem_context *

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix potential context UAFs (rev2)

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 8160 bytes --]

== Series Details ==

Series: drm/i915: Fix potential context UAFs (rev2)
URL   : https://patchwork.freedesktop.org/series/112383/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12546 -> Patchwork_112383v2
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/index.html

Participating hosts (43 -> 44)
------------------------------

  Additional (2): fi-kbl-soraka bat-dg2-oem1 
  Missing    (1): fi-snb-2520m 

Known issues
------------

  Here are the changes found in Patchwork_112383v2 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_gttfill@basic:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][1] ([fdo#109271]) +7 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-kbl-soraka/igt@gem_exec_gttfill@basic.html

  * igt@gem_exec_suspend@basic-s3@smem:
    - fi-rkl-11600:       NOTRUN -> [FAIL][2] ([fdo#103375])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-rkl-11600/igt@gem_exec_suspend@basic-s3@smem.html

  * igt@gem_huc_copy@huc-copy:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@basic:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html

  * igt@i915_selftest@live@gt_pm:
    - fi-kbl-soraka:      NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@late_gt_pm:
    - fi-glk-j4005:       [PASS][6] -> [DMESG-FAIL][7] ([i915#6217])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@perf:
    - fi-kbl-soraka:      NOTRUN -> [INCOMPLETE][8] ([i915#1886])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-kbl-soraka/igt@i915_selftest@live@perf.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-rkl-11600:       NOTRUN -> [SKIP][9] ([fdo#111827])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-rkl-11600/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +7 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-kbl-soraka/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
    - fi-bsw-n3050:       [PASS][11] -> [FAIL][12] ([i915#6298])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size.html

  * igt@runner@aborted:
    - fi-glk-j4005:       NOTRUN -> [FAIL][13] ([i915#4312])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-glk-j4005/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s0@smem:
    - {bat-adlp-6}:       [DMESG-WARN][14] ([i915#2867]) -> [PASS][15] +2 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-adlp-6/igt@gem_exec_suspend@basic-s0@smem.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/bat-adlp-6/igt@gem_exec_suspend@basic-s0@smem.html

  * igt@i915_selftest@live@reset:
    - {bat-rpls-1}:       [DMESG-FAIL][16] ([i915#4983]) -> [PASS][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-rpls-1/igt@i915_selftest@live@reset.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/bat-rpls-1/igt@i915_selftest@live@reset.html

  * igt@i915_selftest@live@workarounds:
    - {bat-adln-1}:       [INCOMPLETE][18] -> [PASS][19]
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-adln-1/igt@i915_selftest@live@workarounds.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/bat-adln-1/igt@i915_selftest@live@workarounds.html

  
#### Warnings ####

  * igt@i915_suspend@basic-s3-without-i915:
    - fi-rkl-11600:       [INCOMPLETE][20] ([i915#4817]) -> [FAIL][21] ([fdo#103375])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-rkl-11600/igt@i915_suspend@basic-s3-without-i915.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
  [i915#6217]: https://gitlab.freedesktop.org/drm/intel/issues/6217
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
  [i915#7714]: https://gitlab.freedesktop.org/drm/intel/issues/7714


Build changes
-------------

  * Linux: CI_DRM_12546 -> Patchwork_112383v2

  CI-20190529: 20190529
  CI_DRM_12546: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7107: 4f22b49ee353406c14ce8bb3151ebe3ce4e6e9be @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112383v2: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

05cd2f26ef19 drm/i915: Fix potential context UAFs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/index.html

[-- Attachment #2: Type: text/html, Size: 7983 bytes --]

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Andi Shyti]

Hi Rob,

On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> gem_context_register() makes the context visible to userspace, and which
> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> So we need to ensure that nothing uses the ctx ptr after this.  And we
> need to ensure that adding the ctx to the xarray is the *last* thing
> that gem_context_register() does with the ctx pointer.
> 
> Signed-off-by: Rob Clark <robdclark@chromium.org>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

I also agree with Tvrtko that we should add Stable: and Fixes:.

One little thing, "user after free" is clearer that UAF :)

Thanks,
Andi

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7f2831efc798..6250de9b9196 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>  	init_contexts(&i915->gem.contexts);
>  }
>  
> +/*
> + * Note that this implicitly consumes the ctx reference, by placing
> + * the ctx in the context_xa.
> + */
>  static void gem_context_register(struct i915_gem_context *ctx,
>  				 struct drm_i915_file_private *fpriv,
>  				 u32 id)
> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>  	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>  		 current->comm, pid_nr(ctx->pid));
>  
> -	/* And finally expose ourselves to userspace via the idr */
> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> -	WARN_ON(old);
> -
>  	spin_lock(&ctx->client->ctx_lock);
>  	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>  	spin_unlock(&ctx->client->ctx_lock);
> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>  	spin_lock(&i915->gem.contexts.lock);
>  	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>  	spin_unlock(&i915->gem.contexts.lock);
> +
> +	/* And finally expose ourselves to userspace via the idr */
> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> +	WARN_ON(old);
>  }
>  
>  int i915_gem_context_open(struct drm_i915_private *i915,
> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>  	if (IS_ERR(ctx))
>  		return ctx;
>  
> +	/*
> +	 * One for the xarray and one for the caller.  We need to grab
> +	 * the reference *prior* to making the ctx visble to userspace
> +	 * in gem_context_register(), as at any point after that
> +	 * userspace can try to race us with another thread destroying
> +	 * the context under our feet.
> +	 */
> +	i915_gem_context_get(ctx);
> +
>  	gem_context_register(ctx, file_priv, id);
>  
>  	old = xa_erase(&file_priv->proto_context_xa, id);
>  	GEM_BUG_ON(old != pc);
>  	proto_context_close(file_priv->dev_priv, pc);
>  
> -	/* One for the xarray and one for the caller */
> -	return i915_gem_context_get(ctx);
> +	return ctx;
>  }
>  
>  struct i915_gem_context *
> -- 
> 2.38.1

Re: [PATCH] drm/i915: Fix potential context UAFs

[Andi Shyti]

Hi Rob,

On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> gem_context_register() makes the context visible to userspace, and which
> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> So we need to ensure that nothing uses the ctx ptr after this.  And we
> need to ensure that adding the ctx to the xarray is the *last* thing
> that gem_context_register() does with the ctx pointer.
> 
> Signed-off-by: Rob Clark <robdclark@chromium.org>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

I also agree with Tvrtko that we should add Stable: and Fixes:.

One little thing, "user after free" is clearer that UAF :)

Thanks,
Andi

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7f2831efc798..6250de9b9196 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>  	init_contexts(&i915->gem.contexts);
>  }
>  
> +/*
> + * Note that this implicitly consumes the ctx reference, by placing
> + * the ctx in the context_xa.
> + */
>  static void gem_context_register(struct i915_gem_context *ctx,
>  				 struct drm_i915_file_private *fpriv,
>  				 u32 id)
> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>  	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>  		 current->comm, pid_nr(ctx->pid));
>  
> -	/* And finally expose ourselves to userspace via the idr */
> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> -	WARN_ON(old);
> -
>  	spin_lock(&ctx->client->ctx_lock);
>  	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>  	spin_unlock(&ctx->client->ctx_lock);
> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>  	spin_lock(&i915->gem.contexts.lock);
>  	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>  	spin_unlock(&i915->gem.contexts.lock);
> +
> +	/* And finally expose ourselves to userspace via the idr */
> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> +	WARN_ON(old);
>  }
>  
>  int i915_gem_context_open(struct drm_i915_private *i915,
> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>  	if (IS_ERR(ctx))
>  		return ctx;
>  
> +	/*
> +	 * One for the xarray and one for the caller.  We need to grab
> +	 * the reference *prior* to making the ctx visble to userspace
> +	 * in gem_context_register(), as at any point after that
> +	 * userspace can try to race us with another thread destroying
> +	 * the context under our feet.
> +	 */
> +	i915_gem_context_get(ctx);
> +
>  	gem_context_register(ctx, file_priv, id);
>  
>  	old = xa_erase(&file_priv->proto_context_xa, id);
>  	GEM_BUG_ON(old != pc);
>  	proto_context_close(file_priv->dev_priv, pc);
>  
> -	/* One for the xarray and one for the caller */
> -	return i915_gem_context_get(ctx);
> +	return ctx;
>  }
>  
>  struct i915_gem_context *
> -- 
> 2.38.1

Re: [PATCH] drm/i915: Fix potential context UAFs

[Andi Shyti]

Hi Rob,

On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> gem_context_register() makes the context visible to userspace, and which
> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> So we need to ensure that nothing uses the ctx ptr after this.  And we
> need to ensure that adding the ctx to the xarray is the *last* thing
> that gem_context_register() does with the ctx pointer.
> 
> Signed-off-by: Rob Clark <robdclark@chromium.org>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

I also agree with Tvrtko that we should add Stable: and Fixes:.

One little thing, "user after free" is clearer that UAF :)

Thanks,
Andi

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7f2831efc798..6250de9b9196 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>  	init_contexts(&i915->gem.contexts);
>  }
>  
> +/*
> + * Note that this implicitly consumes the ctx reference, by placing
> + * the ctx in the context_xa.
> + */
>  static void gem_context_register(struct i915_gem_context *ctx,
>  				 struct drm_i915_file_private *fpriv,
>  				 u32 id)
> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>  	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>  		 current->comm, pid_nr(ctx->pid));
>  
> -	/* And finally expose ourselves to userspace via the idr */
> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> -	WARN_ON(old);
> -
>  	spin_lock(&ctx->client->ctx_lock);
>  	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>  	spin_unlock(&ctx->client->ctx_lock);
> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>  	spin_lock(&i915->gem.contexts.lock);
>  	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>  	spin_unlock(&i915->gem.contexts.lock);
> +
> +	/* And finally expose ourselves to userspace via the idr */
> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
> +	WARN_ON(old);
>  }
>  
>  int i915_gem_context_open(struct drm_i915_private *i915,
> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>  	if (IS_ERR(ctx))
>  		return ctx;
>  
> +	/*
> +	 * One for the xarray and one for the caller.  We need to grab
> +	 * the reference *prior* to making the ctx visble to userspace
> +	 * in gem_context_register(), as at any point after that
> +	 * userspace can try to race us with another thread destroying
> +	 * the context under our feet.
> +	 */
> +	i915_gem_context_get(ctx);
> +
>  	gem_context_register(ctx, file_priv, id);
>  
>  	old = xa_erase(&file_priv->proto_context_xa, id);
>  	GEM_BUG_ON(old != pc);
>  	proto_context_close(file_priv->dev_priv, pc);
>  
> -	/* One for the xarray and one for the caller */
> -	return i915_gem_context_get(ctx);
> +	return ctx;
>  }
>  
>  struct i915_gem_context *
> -- 
> 2.38.1

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 05/01/2023 15:52, Andi Shyti wrote:
> Hi Rob,
> 
> On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
>> From: Rob Clark <robdclark@chromium.org>
>>
>> gem_context_register() makes the context visible to userspace, and which
>> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
>> So we need to ensure that nothing uses the ctx ptr after this.  And we
>> need to ensure that adding the ctx to the xarray is the *last* thing
>> that gem_context_register() does with the ctx pointer.
>>
>> Signed-off-by: Rob Clark <robdclark@chromium.org>
> 
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> 
> I also agree with Tvrtko that we should add Stable: and Fixes:.

Yeah I'll add them all when merging. Just waiting for full CI results. It will be like this:

Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until it is registered")
Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client")
Cc: <stable@vger.kernel.org> # v5.10+

Regards,

Tvrtko
  
> One little thing, "user after free" is clearer that UAF :)
> 
> Thanks,
> Andi
> 
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>>   1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> index 7f2831efc798..6250de9b9196 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>>   	init_contexts(&i915->gem.contexts);
>>   }
>>   
>> +/*
>> + * Note that this implicitly consumes the ctx reference, by placing
>> + * the ctx in the context_xa.
>> + */
>>   static void gem_context_register(struct i915_gem_context *ctx,
>>   				 struct drm_i915_file_private *fpriv,
>>   				 u32 id)
>> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>>   	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>>   		 current->comm, pid_nr(ctx->pid));
>>   
>> -	/* And finally expose ourselves to userspace via the idr */
>> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>> -	WARN_ON(old);
>> -
>>   	spin_lock(&ctx->client->ctx_lock);
>>   	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>>   	spin_unlock(&ctx->client->ctx_lock);
>> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>>   	spin_lock(&i915->gem.contexts.lock);
>>   	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>>   	spin_unlock(&i915->gem.contexts.lock);
>> +
>> +	/* And finally expose ourselves to userspace via the idr */
>> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>> +	WARN_ON(old);
>>   }
>>   
>>   int i915_gem_context_open(struct drm_i915_private *i915,
>> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>>   	if (IS_ERR(ctx))
>>   		return ctx;
>>   
>> +	/*
>> +	 * One for the xarray and one for the caller.  We need to grab
>> +	 * the reference *prior* to making the ctx visble to userspace
>> +	 * in gem_context_register(), as at any point after that
>> +	 * userspace can try to race us with another thread destroying
>> +	 * the context under our feet.
>> +	 */
>> +	i915_gem_context_get(ctx);
>> +
>>   	gem_context_register(ctx, file_priv, id);
>>   
>>   	old = xa_erase(&file_priv->proto_context_xa, id);
>>   	GEM_BUG_ON(old != pc);
>>   	proto_context_close(file_priv->dev_priv, pc);
>>   
>> -	/* One for the xarray and one for the caller */
>> -	return i915_gem_context_get(ctx);
>> +	return ctx;
>>   }
>>   
>>   struct i915_gem_context *
>> -- 
>> 2.38.1

Re: [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 05/01/2023 15:52, Andi Shyti wrote:
> Hi Rob,
> 
> On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
>> From: Rob Clark <robdclark@chromium.org>
>>
>> gem_context_register() makes the context visible to userspace, and which
>> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
>> So we need to ensure that nothing uses the ctx ptr after this.  And we
>> need to ensure that adding the ctx to the xarray is the *last* thing
>> that gem_context_register() does with the ctx pointer.
>>
>> Signed-off-by: Rob Clark <robdclark@chromium.org>
> 
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> 
> I also agree with Tvrtko that we should add Stable: and Fixes:.

Yeah I'll add them all when merging. Just waiting for full CI results. It will be like this:

Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until it is registered")
Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client")
Cc: <stable@vger.kernel.org> # v5.10+

Regards,

Tvrtko
  
> One little thing, "user after free" is clearer that UAF :)
> 
> Thanks,
> Andi
> 
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>>   1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> index 7f2831efc798..6250de9b9196 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>>   	init_contexts(&i915->gem.contexts);
>>   }
>>   
>> +/*
>> + * Note that this implicitly consumes the ctx reference, by placing
>> + * the ctx in the context_xa.
>> + */
>>   static void gem_context_register(struct i915_gem_context *ctx,
>>   				 struct drm_i915_file_private *fpriv,
>>   				 u32 id)
>> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>>   	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>>   		 current->comm, pid_nr(ctx->pid));
>>   
>> -	/* And finally expose ourselves to userspace via the idr */
>> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>> -	WARN_ON(old);
>> -
>>   	spin_lock(&ctx->client->ctx_lock);
>>   	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>>   	spin_unlock(&ctx->client->ctx_lock);
>> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>>   	spin_lock(&i915->gem.contexts.lock);
>>   	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>>   	spin_unlock(&i915->gem.contexts.lock);
>> +
>> +	/* And finally expose ourselves to userspace via the idr */
>> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>> +	WARN_ON(old);
>>   }
>>   
>>   int i915_gem_context_open(struct drm_i915_private *i915,
>> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>>   	if (IS_ERR(ctx))
>>   		return ctx;
>>   
>> +	/*
>> +	 * One for the xarray and one for the caller.  We need to grab
>> +	 * the reference *prior* to making the ctx visble to userspace
>> +	 * in gem_context_register(), as at any point after that
>> +	 * userspace can try to race us with another thread destroying
>> +	 * the context under our feet.
>> +	 */
>> +	i915_gem_context_get(ctx);
>> +
>>   	gem_context_register(ctx, file_priv, id);
>>   
>>   	old = xa_erase(&file_priv->proto_context_xa, id);
>>   	GEM_BUG_ON(old != pc);
>>   	proto_context_close(file_priv->dev_priv, pc);
>>   
>> -	/* One for the xarray and one for the caller */
>> -	return i915_gem_context_get(ctx);
>> +	return ctx;
>>   }
>>   
>>   struct i915_gem_context *
>> -- 
>> 2.38.1

Re: [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 05/01/2023 15:52, Andi Shyti wrote:
> Hi Rob,
> 
> On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
>> From: Rob Clark <robdclark@chromium.org>
>>
>> gem_context_register() makes the context visible to userspace, and which
>> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
>> So we need to ensure that nothing uses the ctx ptr after this.  And we
>> need to ensure that adding the ctx to the xarray is the *last* thing
>> that gem_context_register() does with the ctx pointer.
>>
>> Signed-off-by: Rob Clark <robdclark@chromium.org>
> 
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> 
> I also agree with Tvrtko that we should add Stable: and Fixes:.

Yeah I'll add them all when merging. Just waiting for full CI results. It will be like this:

Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until it is registered")
Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client")
Cc: <stable@vger.kernel.org> # v5.10+

Regards,

Tvrtko
  
> One little thing, "user after free" is clearer that UAF :)
> 
> Thanks,
> Andi
> 
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>>   1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> index 7f2831efc798..6250de9b9196 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
>>   	init_contexts(&i915->gem.contexts);
>>   }
>>   
>> +/*
>> + * Note that this implicitly consumes the ctx reference, by placing
>> + * the ctx in the context_xa.
>> + */
>>   static void gem_context_register(struct i915_gem_context *ctx,
>>   				 struct drm_i915_file_private *fpriv,
>>   				 u32 id)
>> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context *ctx,
>>   	snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>>   		 current->comm, pid_nr(ctx->pid));
>>   
>> -	/* And finally expose ourselves to userspace via the idr */
>> -	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>> -	WARN_ON(old);
>> -
>>   	spin_lock(&ctx->client->ctx_lock);
>>   	list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>>   	spin_unlock(&ctx->client->ctx_lock);
>> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context *ctx,
>>   	spin_lock(&i915->gem.contexts.lock);
>>   	list_add_tail(&ctx->link, &i915->gem.contexts.list);
>>   	spin_unlock(&i915->gem.contexts.lock);
>> +
>> +	/* And finally expose ourselves to userspace via the idr */
>> +	old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>> +	WARN_ON(old);
>>   }
>>   
>>   int i915_gem_context_open(struct drm_i915_private *i915,
>> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>>   	if (IS_ERR(ctx))
>>   		return ctx;
>>   
>> +	/*
>> +	 * One for the xarray and one for the caller.  We need to grab
>> +	 * the reference *prior* to making the ctx visble to userspace
>> +	 * in gem_context_register(), as at any point after that
>> +	 * userspace can try to race us with another thread destroying
>> +	 * the context under our feet.
>> +	 */
>> +	i915_gem_context_get(ctx);
>> +
>>   	gem_context_register(ctx, file_priv, id);
>>   
>>   	old = xa_erase(&file_priv->proto_context_xa, id);
>>   	GEM_BUG_ON(old != pc);
>>   	proto_context_close(file_priv->dev_priv, pc);
>>   
>> -	/* One for the xarray and one for the caller */
>> -	return i915_gem_context_get(ctx);
>> +	return ctx;
>>   }
>>   
>>   struct i915_gem_context *
>> -- 
>> 2.38.1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix potential context UAFs (rev2)

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 18163 bytes --]

== Series Details ==

Series: drm/i915: Fix potential context UAFs (rev2)
URL   : https://patchwork.freedesktop.org/series/112383/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12546_full -> Patchwork_112383v2_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/index.html

Participating hosts (13 -> 11)
------------------------------

  Additional (1): shard-rkl0 
  Missing    (3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 

Known issues
------------

  Here are the changes found in Patchwork_112383v2_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-glk:          [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk5/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-glk6/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
    - shard-glk:          [PASS][3] -> [FAIL][4] ([i915#2346])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk6/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-glk2/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions.html

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
    - shard-glk:          NOTRUN -> [SKIP][5] ([fdo#109271])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-glk7/igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1.html

  * igt@kms_vblank@pipe-c-accuracy-idle:
    - shard-glk:          [PASS][6] -> [FAIL][7] ([i915#43])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk4/igt@kms_vblank@pipe-c-accuracy-idle.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-glk2/igt@kms_vblank@pipe-c-accuracy-idle.html

  
#### Possible fixes ####

  * igt@feature_discovery@psr1:
    - {shard-rkl}:        [SKIP][8] ([i915#658]) -> [PASS][9]
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-2/igt@feature_discovery@psr1.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-6/igt@feature_discovery@psr1.html

  * igt@gem_eio@suspend:
    - {shard-rkl}:        [FAIL][10] ([i915#7052]) -> [PASS][11]
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-4/igt@gem_eio@suspend.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-1/igt@gem_eio@suspend.html

  * igt@gem_exec_balancer@fairslice:
    - {shard-rkl}:        [SKIP][12] ([i915#6259]) -> [PASS][13]
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-5/igt@gem_exec_balancer@fairslice.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-3/igt@gem_exec_balancer@fairslice.html

  * igt@gem_exec_reloc@basic-write-gtt-noreloc:
    - {shard-rkl}:        [SKIP][14] ([i915#3281]) -> [PASS][15] +4 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-6/igt@gem_exec_reloc@basic-write-gtt-noreloc.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-5/igt@gem_exec_reloc@basic-write-gtt-noreloc.html

  * igt@gem_readwrite@new-obj:
    - {shard-rkl}:        [SKIP][16] ([i915#3282]) -> [PASS][17] +2 similar issues
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-3/igt@gem_readwrite@new-obj.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-5/igt@gem_readwrite@new-obj.html

  * igt@gen9_exec_parse@bb-start-out:
    - {shard-rkl}:        [SKIP][18] ([i915#2527]) -> [PASS][19] +1 similar issue
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-3/igt@gen9_exec_parse@bb-start-out.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-5/igt@gen9_exec_parse@bb-start-out.html

  * igt@i915_pm_rc6_residency@rc6-idle@vcs0:
    - {shard-rkl}:        [WARN][20] ([i915#2681]) -> [PASS][21]
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-5/igt@i915_pm_rc6_residency@rc6-idle@vcs0.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-3/igt@i915_pm_rc6_residency@rc6-idle@vcs0.html

  * igt@i915_pm_rpm@modeset-lpsp-stress:
    - {shard-rkl}:        [SKIP][22] ([i915#1397]) -> [PASS][23] +1 similar issue
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-2/igt@i915_pm_rpm@modeset-lpsp-stress.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-6/igt@i915_pm_rpm@modeset-lpsp-stress.html

  * igt@i915_selftest@live@gt_heartbeat:
    - shard-glk:          [DMESG-FAIL][24] ([i915#5334]) -> [PASS][25]
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-glk5/igt@i915_selftest@live@gt_heartbeat.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-glk6/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_pm:
    - {shard-rkl}:        [DMESG-FAIL][26] ([i915#4258]) -> [PASS][27]
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-6/igt@i915_selftest@live@gt_pm.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-5/igt@i915_selftest@live@gt_pm.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
    - {shard-tglu}:       [SKIP][28] ([i915#1845] / [i915#7651]) -> [PASS][29] +2 similar issues
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-tglu-6/igt@kms_big_fb@y-tiled-64bpp-rotate-180.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-tglu-5/igt@kms_big_fb@y-tiled-64bpp-rotate-180.html

  * igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
    - {shard-tglu}:       [SKIP][30] ([i915#7651]) -> [PASS][31] +10 similar issues
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-tglu-6/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-tglu-5/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
    - {shard-rkl}:        [SKIP][32] ([i915#1849] / [i915#4098]) -> [PASS][33] +16 similar issues
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-2/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-6/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:
    - {shard-tglu}:       [SKIP][34] ([i915#1849]) -> [PASS][35] +4 similar issues
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-tglu-6/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-tglu-5/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes.html

  * igt@kms_psr@cursor_mmap_cpu:
    - {shard-rkl}:        [SKIP][36] ([i915#1072]) -> [PASS][37] +2 similar issues
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-5/igt@kms_psr@cursor_mmap_cpu.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-6/igt@kms_psr@cursor_mmap_cpu.html

  * igt@kms_psr_stress_test@flip-primary-invalidate-overlay:
    - {shard-rkl}:        [SKIP][38] ([i915#5461]) -> [PASS][39]
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-5/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-6/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html

  * igt@kms_rotation_crc@primary-rotation-90:
    - {shard-rkl}:        [SKIP][40] ([i915#1845] / [i915#4098]) -> [PASS][41] +25 similar issues
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-2/igt@kms_rotation_crc@primary-rotation-90.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-6/igt@kms_rotation_crc@primary-rotation-90.html

  * igt@kms_universal_plane@cursor-fb-leak-pipe-b:
    - {shard-tglu}:       [SKIP][42] ([fdo#109274]) -> [PASS][43]
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-tglu-6/igt@kms_universal_plane@cursor-fb-leak-pipe-b.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-tglu-5/igt@kms_universal_plane@cursor-fb-leak-pipe-b.html

  * igt@testdisplay:
    - {shard-rkl}:        [SKIP][44] ([i915#4098]) -> [PASS][45] +1 similar issue
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/shard-rkl-2/igt@testdisplay.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/shard-rkl-6/igt@testdisplay.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
  [fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#109302]: https://bugs.freedesktop.org/show_bug.cgi?id=109302
  [fdo#109307]: https://bugs.freedesktop.org/show_bug.cgi?id=109307
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#109312]: https://bugs.freedesktop.org/show_bug.cgi?id=109312
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#110542]: https://bugs.freedesktop.org/show_bug.cgi?id=110542
  [fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111644]: https://bugs.freedesktop.org/show_bug.cgi?id=111644
  [fdo#111656]: https://bugs.freedesktop.org/show_bug.cgi?id=111656
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [fdo#112054]: https://bugs.freedesktop.org/show_bug.cgi?id=112054
  [fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#132]: https://gitlab.freedesktop.org/drm/intel/issues/132
  [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
  [i915#1722]: https://gitlab.freedesktop.org/drm/intel/issues/1722
  [i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
  [i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
  [i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
  [i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
  [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
  [i915#2681]: https://gitlab.freedesktop.org/drm/intel/issues/2681
  [i915#280]: https://gitlab.freedesktop.org/drm/intel/issues/280
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
  [i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
  [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
  [i915#3116]: https://gitlab.freedesktop.org/drm/intel/issues/3116
  [i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
  [i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
  [i915#3469]: https://gitlab.freedesktop.org/drm/intel/issues/3469
  [i915#3528]: https://gitlab.freedesktop.org/drm/intel/issues/3528
  [i915#3536]: https://gitlab.freedesktop.org/drm/intel/issues/3536
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#3547]: https://gitlab.freedesktop.org/drm/intel/issues/3547
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3558]: https://gitlab.freedesktop.org/drm/intel/issues/3558
  [i915#3591]: https://gitlab.freedesktop.org/drm/intel/issues/3591
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
  [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#3734]: https://gitlab.freedesktop.org/drm/intel/issues/3734
  [i915#3742]: https://gitlab.freedesktop.org/drm/intel/issues/3742
  [i915#3778]: https://gitlab.freedesktop.org/drm/intel/issues/3778
  [i915#3825]: https://gitlab.freedesktop.org/drm/intel/issues/3825
  [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
  [i915#404]: https://gitlab.freedesktop.org/drm/intel/issues/404
  [i915#4070]: https://gitlab.freedesktop.org/drm/intel/issues/4070
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#426]: https://gitlab.freedesktop.org/drm/intel/issues/426
  [i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
  [i915#43]: https://gitlab.freedesktop.org/drm/intel/issues/43
  [i915#4387]: https://gitlab.freedesktop.org/drm/intel/issues/4387
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4767]: https://gitlab.freedesktop.org/drm/intel/issues/4767
  [i915#4877]: https://gitlab.freedesktop.org/drm/intel/issues/4877
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
  [i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
  [i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
  [i915#5288]: https://gitlab.freedesktop.org/drm/intel/issues/5288
  [i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289
  [i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5439]: https://gitlab.freedesktop.org/drm/intel/issues/5439
  [i915#5461]: https://gitlab.freedesktop.org/drm/intel/issues/5461
  [i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
  [i915#6227]: https://gitlab.freedesktop.org/drm/intel/issues/6227
  [i915#6230]: https://gitlab.freedesktop.org/drm/intel/issues/6230
  [i915#6248]: https://gitlab.freedesktop.org/drm/intel/issues/6248
  [i915#6259]: https://gitlab.freedesktop.org/drm/intel/issues/6259
  [i915#6268]: https://gitlab.freedesktop.org/drm/intel/issues/6268
  [i915#6335]: https://gitlab.freedesktop.org/drm/intel/issues/6335
  [i915#6433]: https://gitlab.freedesktop.org/drm/intel/issues/6433
  [i915#6463]: https://gitlab.freedesktop.org/drm/intel/issues/6463
  [i915#6497]: https://gitlab.freedesktop.org/drm/intel/issues/6497
  [i915#6524]: https://gitlab.freedesktop.org/drm/intel/issues/6524
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#6590]: https://gitlab.freedesktop.org/drm/intel/issues/6590
  [i915#6768]: https://gitlab.freedesktop.org/drm/intel/issues/6768
  [i915#6944]: https://gitlab.freedesktop.org/drm/intel/issues/6944
  [i915#7037]: https://gitlab.freedesktop.org/drm/intel/issues/7037
  [i915#7052]: https://gitlab.freedesktop.org/drm/intel/issues/7052
  [i915#7116]: https://gitlab.freedesktop.org/drm/intel/issues/7116
  [i915#7118]: https://gitlab.freedesktop.org/drm/intel/issues/7118
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
  [i915#7582]: https://gitlab.freedesktop.org/drm/intel/issues/7582
  [i915#7651]: https://gitlab.freedesktop.org/drm/intel/issues/7651
  [i915#7681]: https://gitlab.freedesktop.org/drm/intel/issues/7681
  [i915#7697]: https://gitlab.freedesktop.org/drm/intel/issues/7697
  [i915#7701]: https://gitlab.freedesktop.org/drm/intel/issues/7701
  [i915#7707]: https://gitlab.freedesktop.org/drm/intel/issues/7707
  [i915#7742]: https://gitlab.freedesktop.org/drm/intel/issues/7742


Build changes
-------------

  * Linux: CI_DRM_12546 -> Patchwork_112383v2
  * Piglit: piglit_4509 -> None

  CI-20190529: 20190529
  CI_DRM_12546: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7107: 4f22b49ee353406c14ce8bb3151ebe3ce4e6e9be @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112383v2: 07a684fbd4d0f5e284e8a782e0298f772fc4164e @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/index.html

[-- Attachment #2: Type: text/html, Size: 12833 bytes --]

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 05/01/2023 16:00, Tvrtko Ursulin wrote:
> 
> On 05/01/2023 15:52, Andi Shyti wrote:
>> Hi Rob,
>>
>> On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
>>> From: Rob Clark <robdclark@chromium.org>
>>>
>>> gem_context_register() makes the context visible to userspace, and which
>>> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
>>> So we need to ensure that nothing uses the ctx ptr after this.  And we
>>> need to ensure that adding the ctx to the xarray is the *last* thing
>>> that gem_context_register() does with the ctx pointer.
>>>
>>> Signed-off-by: Rob Clark <robdclark@chromium.org>
>>
>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>>
>> I also agree with Tvrtko that we should add Stable: and Fixes:.
> 
> Yeah I'll add them all when merging. Just waiting for full CI results. 
> It will be like this:
> 
> Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until 
> it is registered")
> Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
> Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client")
> Cc: <stable@vger.kernel.org> # v5.10+

Pushed to drm-intel-gt-next - thanks for the fix and reviews.

Regards,

Tvrtko

> 
> Regards,
> 
> Tvrtko
> 
>> One little thing, "user after free" is clearer that UAF :)
>>
>> Thanks,
>> Andi
>>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>>>   1 file changed, 18 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> index 7f2831efc798..6250de9b9196 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct 
>>> drm_i915_private *i915)
>>>       init_contexts(&i915->gem.contexts);
>>>   }
>>> +/*
>>> + * Note that this implicitly consumes the ctx reference, by placing
>>> + * the ctx in the context_xa.
>>> + */
>>>   static void gem_context_register(struct i915_gem_context *ctx,
>>>                    struct drm_i915_file_private *fpriv,
>>>                    u32 id)
>>> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct 
>>> i915_gem_context *ctx,
>>>       snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>>>            current->comm, pid_nr(ctx->pid));
>>> -    /* And finally expose ourselves to userspace via the idr */
>>> -    old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>>> -    WARN_ON(old);
>>> -
>>>       spin_lock(&ctx->client->ctx_lock);
>>>       list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>>>       spin_unlock(&ctx->client->ctx_lock);
>>> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct 
>>> i915_gem_context *ctx,
>>>       spin_lock(&i915->gem.contexts.lock);
>>>       list_add_tail(&ctx->link, &i915->gem.contexts.list);
>>>       spin_unlock(&i915->gem.contexts.lock);
>>> +
>>> +    /* And finally expose ourselves to userspace via the idr */
>>> +    old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>>> +    WARN_ON(old);
>>>   }
>>>   int i915_gem_context_open(struct drm_i915_private *i915,
>>> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct 
>>> drm_i915_file_private *file_priv,
>>>       if (IS_ERR(ctx))
>>>           return ctx;
>>> +    /*
>>> +     * One for the xarray and one for the caller.  We need to grab
>>> +     * the reference *prior* to making the ctx visble to userspace
>>> +     * in gem_context_register(), as at any point after that
>>> +     * userspace can try to race us with another thread destroying
>>> +     * the context under our feet.
>>> +     */
>>> +    i915_gem_context_get(ctx);
>>> +
>>>       gem_context_register(ctx, file_priv, id);
>>>       old = xa_erase(&file_priv->proto_context_xa, id);
>>>       GEM_BUG_ON(old != pc);
>>>       proto_context_close(file_priv->dev_priv, pc);
>>> -    /* One for the xarray and one for the caller */
>>> -    return i915_gem_context_get(ctx);
>>> +    return ctx;
>>>   }
>>>   struct i915_gem_context *
>>> -- 
>>> 2.38.1

Re: [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 05/01/2023 16:00, Tvrtko Ursulin wrote:
> 
> On 05/01/2023 15:52, Andi Shyti wrote:
>> Hi Rob,
>>
>> On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
>>> From: Rob Clark <robdclark@chromium.org>
>>>
>>> gem_context_register() makes the context visible to userspace, and which
>>> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
>>> So we need to ensure that nothing uses the ctx ptr after this.  And we
>>> need to ensure that adding the ctx to the xarray is the *last* thing
>>> that gem_context_register() does with the ctx pointer.
>>>
>>> Signed-off-by: Rob Clark <robdclark@chromium.org>
>>
>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>>
>> I also agree with Tvrtko that we should add Stable: and Fixes:.
> 
> Yeah I'll add them all when merging. Just waiting for full CI results. 
> It will be like this:
> 
> Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until 
> it is registered")
> Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
> Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client")
> Cc: <stable@vger.kernel.org> # v5.10+

Pushed to drm-intel-gt-next - thanks for the fix and reviews.

Regards,

Tvrtko

> 
> Regards,
> 
> Tvrtko
> 
>> One little thing, "user after free" is clearer that UAF :)
>>
>> Thanks,
>> Andi
>>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>>>   1 file changed, 18 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> index 7f2831efc798..6250de9b9196 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct 
>>> drm_i915_private *i915)
>>>       init_contexts(&i915->gem.contexts);
>>>   }
>>> +/*
>>> + * Note that this implicitly consumes the ctx reference, by placing
>>> + * the ctx in the context_xa.
>>> + */
>>>   static void gem_context_register(struct i915_gem_context *ctx,
>>>                    struct drm_i915_file_private *fpriv,
>>>                    u32 id)
>>> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct 
>>> i915_gem_context *ctx,
>>>       snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>>>            current->comm, pid_nr(ctx->pid));
>>> -    /* And finally expose ourselves to userspace via the idr */
>>> -    old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>>> -    WARN_ON(old);
>>> -
>>>       spin_lock(&ctx->client->ctx_lock);
>>>       list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>>>       spin_unlock(&ctx->client->ctx_lock);
>>> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct 
>>> i915_gem_context *ctx,
>>>       spin_lock(&i915->gem.contexts.lock);
>>>       list_add_tail(&ctx->link, &i915->gem.contexts.list);
>>>       spin_unlock(&i915->gem.contexts.lock);
>>> +
>>> +    /* And finally expose ourselves to userspace via the idr */
>>> +    old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>>> +    WARN_ON(old);
>>>   }
>>>   int i915_gem_context_open(struct drm_i915_private *i915,
>>> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct 
>>> drm_i915_file_private *file_priv,
>>>       if (IS_ERR(ctx))
>>>           return ctx;
>>> +    /*
>>> +     * One for the xarray and one for the caller.  We need to grab
>>> +     * the reference *prior* to making the ctx visble to userspace
>>> +     * in gem_context_register(), as at any point after that
>>> +     * userspace can try to race us with another thread destroying
>>> +     * the context under our feet.
>>> +     */
>>> +    i915_gem_context_get(ctx);
>>> +
>>>       gem_context_register(ctx, file_priv, id);
>>>       old = xa_erase(&file_priv->proto_context_xa, id);
>>>       GEM_BUG_ON(old != pc);
>>>       proto_context_close(file_priv->dev_priv, pc);
>>> -    /* One for the xarray and one for the caller */
>>> -    return i915_gem_context_get(ctx);
>>> +    return ctx;
>>>   }
>>>   struct i915_gem_context *
>>> -- 
>>> 2.38.1

Re: [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 05/01/2023 16:00, Tvrtko Ursulin wrote:
> 
> On 05/01/2023 15:52, Andi Shyti wrote:
>> Hi Rob,
>>
>> On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
>>> From: Rob Clark <robdclark@chromium.org>
>>>
>>> gem_context_register() makes the context visible to userspace, and which
>>> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
>>> So we need to ensure that nothing uses the ctx ptr after this.  And we
>>> need to ensure that adding the ctx to the xarray is the *last* thing
>>> that gem_context_register() does with the ctx pointer.
>>>
>>> Signed-off-by: Rob Clark <robdclark@chromium.org>
>>
>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>>
>> I also agree with Tvrtko that we should add Stable: and Fixes:.
> 
> Yeah I'll add them all when merging. Just waiting for full CI results. 
> It will be like this:
> 
> Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until 
> it is registered")
> Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
> Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client")
> Cc: <stable@vger.kernel.org> # v5.10+

Pushed to drm-intel-gt-next - thanks for the fix and reviews.

Regards,

Tvrtko

> 
> Regards,
> 
> Tvrtko
> 
>> One little thing, "user after free" is clearer that UAF :)
>>
>> Thanks,
>> Andi
>>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++++++++++++++------
>>>   1 file changed, 18 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> index 7f2831efc798..6250de9b9196 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>>> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct 
>>> drm_i915_private *i915)
>>>       init_contexts(&i915->gem.contexts);
>>>   }
>>> +/*
>>> + * Note that this implicitly consumes the ctx reference, by placing
>>> + * the ctx in the context_xa.
>>> + */
>>>   static void gem_context_register(struct i915_gem_context *ctx,
>>>                    struct drm_i915_file_private *fpriv,
>>>                    u32 id)
>>> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct 
>>> i915_gem_context *ctx,
>>>       snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>>>            current->comm, pid_nr(ctx->pid));
>>> -    /* And finally expose ourselves to userspace via the idr */
>>> -    old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>>> -    WARN_ON(old);
>>> -
>>>       spin_lock(&ctx->client->ctx_lock);
>>>       list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
>>>       spin_unlock(&ctx->client->ctx_lock);
>>> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct 
>>> i915_gem_context *ctx,
>>>       spin_lock(&i915->gem.contexts.lock);
>>>       list_add_tail(&ctx->link, &i915->gem.contexts.list);
>>>       spin_unlock(&i915->gem.contexts.lock);
>>> +
>>> +    /* And finally expose ourselves to userspace via the idr */
>>> +    old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
>>> +    WARN_ON(old);
>>>   }
>>>   int i915_gem_context_open(struct drm_i915_private *i915,
>>> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct 
>>> drm_i915_file_private *file_priv,
>>>       if (IS_ERR(ctx))
>>>           return ctx;
>>> +    /*
>>> +     * One for the xarray and one for the caller.  We need to grab
>>> +     * the reference *prior* to making the ctx visble to userspace
>>> +     * in gem_context_register(), as at any point after that
>>> +     * userspace can try to race us with another thread destroying
>>> +     * the context under our feet.
>>> +     */
>>> +    i915_gem_context_get(ctx);
>>> +
>>>       gem_context_register(ctx, file_priv, id);
>>>       old = xa_erase(&file_priv->proto_context_xa, id);
>>>       GEM_BUG_ON(old != pc);
>>>       proto_context_close(file_priv->dev_priv, pc);
>>> -    /* One for the xarray and one for the caller */
>>> -    return i915_gem_context_get(ctx);
>>> +    return ctx;
>>>   }
>>>   struct i915_gem_context *
>>> -- 
>>> 2.38.1