* [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-03 23:49 ` Rob Clark
0 siblings, 0 replies; 21+ messages in thread
From: Rob Clark @ 2023-01-03 23:49 UTC (permalink / raw)
To: dri-devel
Cc: Rob Clark, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter, Chris Wilson,
Andi Shyti, John Harrison, Matthew Brost, katrinzhou,
Thomas Hellström, open list:INTEL DRM DRIVERS, open list
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-03 23:49 ` Rob Clark
0 siblings, 0 replies; 21+ messages in thread
From: Rob Clark @ 2023-01-03 23:49 UTC (permalink / raw)
To: dri-devel
Cc: Rob Clark, Tvrtko Ursulin, Matthew Brost, Andi Shyti,
Thomas Hellström, open list:INTEL DRM DRIVERS, open list,
Chris Wilson, Rodrigo Vivi, John Harrison, katrinzhou
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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs
2023-01-03 23:49 ` Rob Clark
(?)
@ 2023-01-04 9:33 ` Tvrtko Ursulin
-1 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-04 9:33 UTC (permalink / raw)
To: Rob Clark, dri-devel
Cc: Rob Clark, Thomas Hellström, open list:INTEL DRM DRIVERS,
open list, Chris Wilson, Daniel Vetter, Rodrigo Vivi,
David Airlie, katrinzhou
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 *
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-04 9:33 ` Tvrtko Ursulin
0 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-04 9:33 UTC (permalink / raw)
To: Rob Clark, dri-devel
Cc: Rob Clark, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Chris Wilson, Andi Shyti,
John Harrison, Matthew Brost, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list
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 *
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-04 9:33 ` Tvrtko Ursulin
0 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-04 9:33 UTC (permalink / raw)
To: Rob Clark, dri-devel
Cc: Rob Clark, Matthew Brost, Andi Shyti, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list, Chris Wilson,
Rodrigo Vivi, John Harrison, katrinzhou
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 *
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs
2023-01-04 9:33 ` Tvrtko Ursulin
(?)
@ 2023-01-04 16:01 ` Rob Clark
-1 siblings, 0 replies; 21+ messages in thread
From: Rob Clark @ 2023-01-04 16:01 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: Rob Clark, Thomas Hellström, open list:INTEL DRM DRIVERS,
open list, Chris Wilson, dri-devel, Daniel Vetter, Rodrigo Vivi,
David Airlie, katrinzhou
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 *
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-04 16:01 ` Rob Clark
0 siblings, 0 replies; 21+ messages in thread
From: Rob Clark @ 2023-01-04 16:01 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: dri-devel, Rob Clark, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Chris Wilson, Andi Shyti,
John Harrison, Matthew Brost, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list
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 *
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-04 16:01 ` Rob Clark
0 siblings, 0 replies; 21+ messages in thread
From: Rob Clark @ 2023-01-04 16:01 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: Rob Clark, Matthew Brost, Andi Shyti, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list, Chris Wilson, dri-devel,
Rodrigo Vivi, John Harrison, katrinzhou
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 *
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix potential context UAFs
2023-01-03 23:49 ` Rob Clark
` (2 preceding siblings ...)
(?)
@ 2023-01-04 13:41 ` Patchwork
-1 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2023-01-04 13:41 UTC (permalink / raw)
To: Rob Clark; +Cc: intel-gfx
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix potential context UAFs (rev2)
2023-01-03 23:49 ` Rob Clark
` (3 preceding siblings ...)
(?)
@ 2023-01-05 12:33 ` Patchwork
-1 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2023-01-05 12:33 UTC (permalink / raw)
To: Rob Clark; +Cc: intel-gfx
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs
2023-01-03 23:49 ` Rob Clark
(?)
@ 2023-01-05 15:52 ` Andi Shyti
-1 siblings, 0 replies; 21+ messages in thread
From: Andi Shyti @ 2023-01-05 15:52 UTC (permalink / raw)
To: Rob Clark
Cc: Rob Clark, Thomas Hellström, open list:INTEL DRM DRIVERS,
open list, Chris Wilson, dri-devel, Daniel Vetter, Rodrigo Vivi,
David Airlie, katrinzhou
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-05 15:52 ` Andi Shyti
0 siblings, 0 replies; 21+ messages in thread
From: Andi Shyti @ 2023-01-05 15:52 UTC (permalink / raw)
To: Rob Clark
Cc: dri-devel, Rob Clark, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter, Chris Wilson,
Andi Shyti, John Harrison, Matthew Brost, katrinzhou,
Thomas Hellström, open list:INTEL DRM DRIVERS, open list
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-05 15:52 ` Andi Shyti
0 siblings, 0 replies; 21+ messages in thread
From: Andi Shyti @ 2023-01-05 15:52 UTC (permalink / raw)
To: Rob Clark
Cc: Rob Clark, Tvrtko Ursulin, Matthew Brost, Andi Shyti,
Thomas Hellström, open list:INTEL DRM DRIVERS, open list,
Chris Wilson, dri-devel, Rodrigo Vivi, John Harrison, katrinzhou
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs
2023-01-05 15:52 ` Andi Shyti
(?)
@ 2023-01-05 16:00 ` Tvrtko Ursulin
-1 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-05 16:00 UTC (permalink / raw)
To: Andi Shyti, Rob Clark
Cc: Rob Clark, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list, Chris Wilson, dri-devel,
Daniel Vetter, Rodrigo Vivi, David Airlie
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-05 16:00 ` Tvrtko Ursulin
0 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-05 16:00 UTC (permalink / raw)
To: Andi Shyti, Rob Clark
Cc: dri-devel, Rob Clark, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Chris Wilson, John Harrison,
Matthew Brost, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-05 16:00 ` Tvrtko Ursulin
0 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-05 16:00 UTC (permalink / raw)
To: Andi Shyti, Rob Clark
Cc: Rob Clark, Matthew Brost, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list, Chris Wilson, dri-devel,
Rodrigo Vivi, John Harrison
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs
2023-01-05 16:00 ` Tvrtko Ursulin
(?)
@ 2023-01-06 10:15 ` Tvrtko Ursulin
-1 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-06 10:15 UTC (permalink / raw)
To: Andi Shyti, Rob Clark
Cc: Rob Clark, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list, Chris Wilson, dri-devel,
Daniel Vetter, Rodrigo Vivi, David Airlie
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-06 10:15 ` Tvrtko Ursulin
0 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-06 10:15 UTC (permalink / raw)
To: Andi Shyti, Rob Clark
Cc: dri-devel, Rob Clark, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Chris Wilson, John Harrison,
Matthew Brost, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH] drm/i915: Fix potential context UAFs
@ 2023-01-06 10:15 ` Tvrtko Ursulin
0 siblings, 0 replies; 21+ messages in thread
From: Tvrtko Ursulin @ 2023-01-06 10:15 UTC (permalink / raw)
To: Andi Shyti, Rob Clark
Cc: Rob Clark, Matthew Brost, katrinzhou, Thomas Hellström,
open list:INTEL DRM DRIVERS, open list, Chris Wilson, dri-devel,
Rodrigo Vivi, John Harrison
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix potential context UAFs (rev2)
2023-01-03 23:49 ` Rob Clark
` (5 preceding siblings ...)
(?)
@ 2023-01-06 9:34 ` Patchwork
-1 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2023-01-06 9:34 UTC (permalink / raw)
To: Rob Clark; +Cc: intel-gfx
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread