--- /dev/null
+From afce71ff6daa9c0f852df0727fe32c6fb107f0fa Mon Sep 17 00:00:00 2001
+From: Rob Clark <robdclark@chromium.org>
+Date: Tue, 3 Jan 2023 15:49:46 -0800
+Subject: drm/i915: Fix potential context UAFs
+
+From: Rob Clark <robdclark@chromium.org>
+
+commit afce71ff6daa9c0f852df0727fe32c6fb107f0fa upstream.
+
+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>
+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+
+Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+[tursulin: Stable and fixes tags add/tidy.]
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230103234948.1218393-1-robdclark@gmail.com
+(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+[ Sherry: bp to fix CVE-2023-52913, ignore context conflicts due to
+ missing commit 49bd54b390c2 "drm/i915: Track all user contexts per
+ client")]
+Signed-off-by: Sherry Yang <sherry.yang@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 ++++++++++++++++++------
+ 1 file changed, 18 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
++++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
+@@ -1436,6 +1436,10 @@ void i915_gem_init__contexts(struct drm_
+ 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)
+@@ -1449,13 +1453,13 @@ static void gem_context_register(struct
+ 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(&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,
+@@ -1932,14 +1936,22 @@ finalize_create_context_locked(struct dr
+ 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(pc);
+
+- /* One for the xarray and one for the caller */
+- return i915_gem_context_get(ctx);
++ return ctx;
+ }
+
+ struct i915_gem_context *
--- /dev/null
+From f956052e00de211b5c9ebaa1958366c23f82ee9e Mon Sep 17 00:00:00 2001
+From: Jeongjun Park <aha310510@gmail.com>
+Date: Fri, 11 Oct 2024 02:46:19 +0900
+Subject: vt: prevent kernel-infoleak in con_font_get()
+
+From: Jeongjun Park <aha310510@gmail.com>
+
+commit f956052e00de211b5c9ebaa1958366c23f82ee9e upstream.
+
+font.data may not initialize all memory spaces depending on the implementation
+of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it
+is safest to modify it to initialize the allocated memory space to 0, and it
+generally does not affect the overall performance of the system.
+
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+955da2d57931604ee691@syzkaller.appspotmail.com
+Fixes: 05e2600cb0a4 ("VT: Bump font size limitation to 64x128 pixels")
+Signed-off-by: Jeongjun Park <aha310510@gmail.com>
+Link: https://lore.kernel.org/r/20241010174619.59662-1-aha310510@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/vt/vt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/vt/vt.c
++++ b/drivers/tty/vt/vt.c
+@@ -4594,7 +4594,7 @@ static int con_font_get(struct vc_data *
+ int c;
+
+ if (op->data) {
+- font.data = kmalloc(max_font_size, GFP_KERNEL);
++ font.data = kzalloc(max_font_size, GFP_KERNEL);
+ if (!font.data)
+ return -ENOMEM;
+ } else