--- /dev/null
+From 4fe2bd195435e71c117983d87f278112c5ab364c Mon Sep 17 00:00:00 2001
+From: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
+Date: Tue, 16 Dec 2025 19:09:01 +0100
+Subject: drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer
+
+From: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
+
+commit 4fe2bd195435e71c117983d87f278112c5ab364c upstream.
+
+Initialize the eb.vma array with values of 0 when the eb structure is
+first set up. In particular, this sets the eb->vma[i].vma pointers to
+NULL, simplifying cleanup and getting rid of the bug described below.
+
+During the execution of eb_lookup_vmas(), the eb->vma array is
+successively filled up with struct eb_vma objects. This process includes
+calling eb_add_vma(), which might fail; however, even in the event of
+failure, eb->vma[i].vma is set for the currently processed buffer.
+
+If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which
+prompts a call to eb_release_vmas() to clean up the mess. Since
+eb_lookup_vmas() might fail during processing any (possibly not first)
+buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know
+at what point did the lookup function fail.
+
+In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper
+function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is
+set to NULL in case i915_gem_object_userptr_submit_init() fails; the
+current one needs to be cleaned up by eb_release_vmas() at this point,
+so the next one is set. If eb_add_vma() fails, neither the current nor
+the next vma is set to NULL, which is a source of a NULL deref bug
+described in the issue linked in the Closes tag.
+
+When entering eb_lookup_vmas(), the vma pointers are set to the slab
+poison value, instead of NULL. This doesn't matter for the actual
+lookup, since it gets overwritten anyway, however the eb_release_vmas()
+function only recognizes NULL as the stopping value, hence the pointers
+are being set to NULL as they go in case of intermediate failure. This
+patch changes the approach to filling them all with NULL at the start
+instead, rather than handling that manually during failure.
+
+Reported-by: Gangmin Kim <km.kim1503@gmail.com>
+Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15062
+Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
+Cc: stable@vger.kernel.org # 5.16.x
+Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
+Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/20251216180900.54294-2-krzysztof.niemiec@intel.com
+(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 37 +++++++++++--------------
+ 1 file changed, 17 insertions(+), 20 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
++++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+@@ -941,13 +941,13 @@ static int eb_lookup_vmas(struct i915_ex
+ vma = eb_lookup_vma(eb, eb->exec[i].handle);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+- goto err;
++ return err;
+ }
+
+ err = eb_validate_vma(eb, &eb->exec[i], vma);
+ if (unlikely(err)) {
+ i915_vma_put(vma);
+- goto err;
++ return err;
+ }
+
+ err = eb_add_vma(eb, ¤t_batch, i, vma);
+@@ -956,19 +956,8 @@ static int eb_lookup_vmas(struct i915_ex
+
+ if (i915_gem_object_is_userptr(vma->obj)) {
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+- if (err) {
+- if (i + 1 < eb->buffer_count) {
+- /*
+- * Execbuffer code expects last vma entry to be NULL,
+- * since we already initialized this entry,
+- * set the next value to NULL or we mess up
+- * cleanup handling.
+- */
+- eb->vma[i + 1].vma = NULL;
+- }
+-
++ if (err)
+ return err;
+- }
+
+ eb->vma[i].flags |= __EXEC_OBJECT_USERPTR_INIT;
+ eb->args->flags |= __EXEC_USERPTR_USED;
+@@ -976,10 +965,6 @@ static int eb_lookup_vmas(struct i915_ex
+ }
+
+ return 0;
+-
+-err:
+- eb->vma[i].vma = NULL;
+- return err;
+ }
+
+ static int eb_lock_vmas(struct i915_execbuffer *eb)
+@@ -3352,7 +3337,8 @@ i915_gem_do_execbuffer(struct drm_device
+
+ eb.exec = exec;
+ eb.vma = (struct eb_vma *)(exec + args->buffer_count + 1);
+- eb.vma[0].vma = NULL;
++ memset(eb.vma, 0, (args->buffer_count + 1) * sizeof(struct eb_vma));
++
+ eb.batch_pool = NULL;
+
+ eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS;
+@@ -3561,7 +3547,18 @@ i915_gem_execbuffer2_ioctl(struct drm_de
+ if (err)
+ return err;
+
+- /* Allocate extra slots for use by the command parser */
++ /*
++ * Allocate extra slots for use by the command parser.
++ *
++ * Note that this allocation handles two different arrays (the
++ * exec2_list array, and the eventual eb.vma array introduced in
++ * i915_gem_do_execbuffer()), that reside in virtually contiguous
++ * memory. Also note that the allocation intentionally doesn't fill the
++ * area with zeros, because the exec2_list part doesn't need to be, as
++ * it's immediately overwritten by user data a few lines below.
++ * However, the eb.vma part is explicitly zeroed later in
++ * i915_gem_do_execbuffer().
++ */
+ exec2_list = kvmalloc_array(count + 2, eb_element_size(),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (exec2_list == NULL) {
--- /dev/null
+From a846505a193d7492ad3531e33cacfca31e4bcdd1 Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Wed, 29 Oct 2025 15:23:06 +0800
+Subject: drm/mediatek: Fix device node reference leak in mtk_dp_dt_parse()
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit a846505a193d7492ad3531e33cacfca31e4bcdd1 upstream.
+
+The function mtk_dp_dt_parse() calls of_graph_get_endpoint_by_regs()
+to get the endpoint device node, but fails to call of_node_put() to release
+the reference when the function returns. This results in a device node
+reference leak.
+
+Fix this by adding the missing of_node_put() call before returning from
+the function.
+
+Found via static analysis and code review.
+
+Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
+Reviewed-by: CK Hu <ck.hu@mediatek.com>
+Link: https://patchwork.kernel.org/project/dri-devel/patch/20251029072307.10955-1-linmq006@gmail.com/
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/mediatek/mtk_dp.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/mediatek/mtk_dp.c
++++ b/drivers/gpu/drm/mediatek/mtk_dp.c
+@@ -1919,6 +1919,7 @@ static int mtk_dp_dt_parse(struct mtk_dp
+ endpoint = of_graph_get_endpoint_by_regs(pdev->dev.of_node, 1, -1);
+ len = of_property_count_elems_of_size(endpoint,
+ "data-lanes", sizeof(u32));
++ of_node_put(endpoint);
+ if (len < 0 || len > 4 || len == 3) {
+ dev_err(dev, "invalid data lane size: %d\n", len);
+ return -EINVAL;
--- /dev/null
+From 6cb31fba137d45e682ce455b8ea364f44d5d4f98 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ren=C3=A9=20Rebe?= <rene@exactco.de>
+Date: Mon, 8 Dec 2025 14:18:27 +0100
+Subject: drm/mgag200: Fix big-endian support
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: René Rebe <rene@exactco.de>
+
+commit 6cb31fba137d45e682ce455b8ea364f44d5d4f98 upstream.
+
+Unlike the original, deleted Matrox mga driver, the new mgag200 driver
+has the XRGB frame-buffer byte swapped on big-endian "RISC"
+systems. Fix by enabling byte swapping "PowerPC" OPMODE for any
+__BIG_ENDIAN config.
+
+Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
+Signed-off-by: René Rebe <rene@exactco.de>
+Cc: stable@kernel.org
+Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patch.msgid.link/20251208.141827.965103015954471168.rene@exactco.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/mgag200/mgag200_mode.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
++++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
+@@ -173,6 +173,30 @@ static void mgag200_set_startadd(struct
+ WREG_ECRT(0x00, crtcext0);
+ }
+
++/*
++ * Set the opmode for the hardware swapper for Big-Endian processor
++ * support for the frame buffer aperture and DMAWIN space.
++ */
++static void mgag200_set_datasiz(struct mga_device *mdev, u32 format)
++{
++#if defined(__BIG_ENDIAN)
++ u32 opmode = RREG32(MGAREG_OPMODE);
++
++ opmode &= ~(GENMASK(17, 16) | GENMASK(9, 8) | GENMASK(3, 2));
++
++ /* Big-endian byte-swapping */
++ switch (format) {
++ case DRM_FORMAT_RGB565:
++ opmode |= 0x10100;
++ break;
++ case DRM_FORMAT_XRGB8888:
++ opmode |= 0x20200;
++ break;
++ }
++ WREG32(MGAREG_OPMODE, opmode);
++#endif
++}
++
+ void mgag200_init_registers(struct mga_device *mdev)
+ {
+ u8 crtc11, misc;
+@@ -506,6 +530,7 @@ void mgag200_primary_plane_helper_atomic
+ if (!fb)
+ return;
+
++ mgag200_set_datasiz(mdev, fb->format->format);
+ drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state);
+ drm_atomic_for_each_plane_damage(&iter, &damage) {
+ mgag200_handle_damage(mdev, shadow_plane_state->data, fb, &damage);
--- /dev/null
+From 779b68a5bf2764c8ed3aa800e41ba0d5d007e1e7 Mon Sep 17 00:00:00 2001
+From: Akhil P Oommen <akhilpo@oss.qualcomm.com>
+Date: Tue, 18 Nov 2025 14:20:28 +0530
+Subject: drm/msm/a6xx: Fix out of bound IO access in a6xx_get_gmu_registers
+
+From: Akhil P Oommen <akhilpo@oss.qualcomm.com>
+
+commit 779b68a5bf2764c8ed3aa800e41ba0d5d007e1e7 upstream.
+
+REG_A6XX_GMU_AO_AHB_FENCE_CTRL register falls under GMU's register
+range. So, use gmu_write() routines to write to this register.
+
+Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
+Cc: stable@vger.kernel.org
+Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Patchwork: https://patchwork.freedesktop.org/patch/688993/
+Message-ID: <20251118-kaana-gpu-support-v4-1-86eeb8e93fb6@oss.qualcomm.com>
+Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
++++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
+@@ -801,7 +801,7 @@ static void a6xx_get_gmu_registers(struc
+ return;
+
+ /* Set the fence to ALLOW mode so we can access the registers */
+- gpu_write(gpu, REG_A6XX_GMU_AO_AHB_FENCE_CTRL, 0);
++ gmu_write(&a6xx_gpu->gmu, REG_A6XX_GMU_AO_AHB_FENCE_CTRL, 0);
+
+ _a6xx_get_gmu_registers(gpu, a6xx_state, &a6xx_gmu_reglist[2],
+ &a6xx_state->gmu_registers[2], false);
--- /dev/null
+From 560271e10b2c86e95ea35afa9e79822e4847f07a Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Thu, 11 Dec 2025 14:02:54 -0500
+Subject: drm/nouveau/dispnv50: Don't call drm_atomic_get_crtc_state() in prepare_fb
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 560271e10b2c86e95ea35afa9e79822e4847f07a upstream.
+
+Since we recently started warning about uses of this function after the
+atomic check phase completes, we've started getting warnings about this in
+nouveau. It appears a misplaced drm_atomic_get_crtc_state() call has been
+hiding in our .prepare_fb callback for a while.
+
+So, fix this by adding a new nv50_head_atom_get_new() function and use that
+in our .prepare_fb callback instead.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Dave Airlie <airlied@redhat.com>
+Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files")
+Cc: <stable@vger.kernel.org> # v4.18+
+Link: https://patch.msgid.link/20251211190256.396742-1-lyude@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/dispnv50/atom.h | 13 +++++++++++++
+ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
++++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
+@@ -152,8 +152,21 @@ static inline struct nv50_head_atom *
+ nv50_head_atom_get(struct drm_atomic_state *state, struct drm_crtc *crtc)
+ {
+ struct drm_crtc_state *statec = drm_atomic_get_crtc_state(state, crtc);
++
+ if (IS_ERR(statec))
+ return (void *)statec;
++
++ return nv50_head_atom(statec);
++}
++
++static inline struct nv50_head_atom *
++nv50_head_atom_get_new(struct drm_atomic_state *state, struct drm_crtc *crtc)
++{
++ struct drm_crtc_state *statec = drm_atomic_get_new_crtc_state(state, crtc);
++
++ if (!statec)
++ return NULL;
++
+ return nv50_head_atom(statec);
+ }
+
+--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
++++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+@@ -567,7 +567,7 @@ nv50_wndw_prepare_fb(struct drm_plane *p
+ asyw->image.offset[0] = nvbo->offset;
+
+ if (wndw->func->prepare) {
+- asyh = nv50_head_atom_get(asyw->state.state, asyw->state.crtc);
++ asyh = nv50_head_atom_get_new(asyw->state.state, asyw->state.crtc);
+ if (IS_ERR(asyh))
+ return PTR_ERR(asyh);
+
--- /dev/null
+From 491adc6a0f9903c32b05f284df1148de39e8e644 Mon Sep 17 00:00:00 2001
+From: Simon Richter <Simon.Richter@hogyros.de>
+Date: Tue, 14 Oct 2025 01:11:33 +0900
+Subject: drm/ttm: Avoid NULL pointer deref for evicted BOs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Simon Richter <Simon.Richter@hogyros.de>
+
+commit 491adc6a0f9903c32b05f284df1148de39e8e644 upstream.
+
+It is possible for a BO to exist that is not currently associated with a
+resource, e.g. because it has been evicted.
+
+When devcoredump tries to read the contents of all BOs for dumping, we need
+to expect this as well -- in this case, ENODATA is recorded instead of the
+buffer contents.
+
+Fixes: 7d08df5d0bd3 ("drm/ttm: Add ttm_bo_access")
+Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
+Cc: stable <stable@kernel.org>
+Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6271
+Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
+Reviewed-by: Matthew Brost <matthew.brost@intel.com>
+Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Matthew Brost <matthew.brost@intel.com>
+Link: https://patch.msgid.link/20251013161241.709916-1-Simon.Richter@hogyros.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
++++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
+@@ -419,6 +419,11 @@ int ttm_bo_vm_access(struct vm_area_stru
+ if (ret)
+ return ret;
+
++ if (!bo->resource) {
++ ret = -ENODATA;
++ goto unlock;
++ }
++
+ switch (bo->resource->mem_type) {
+ case TTM_PL_SYSTEM:
+ fallthrough;
+@@ -433,6 +438,7 @@ int ttm_bo_vm_access(struct vm_area_stru
+ ret = -EIO;
+ }
+
++unlock:
+ ttm_bo_unreserve(bo);
+
+ return ret;
net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch
net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch
net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch
+drm-msm-a6xx-fix-out-of-bound-io-access-in-a6xx_get_gmu_registers.patch
+drm-mediatek-fix-device-node-reference-leak-in-mtk_dp_dt_parse.patch
+drm-ttm-avoid-null-pointer-deref-for-evicted-bos.patch
+drm-mgag200-fix-big-endian-support.patch
+drm-i915-gem-zero-initialize-the-eb.vma-array-in-i915_gem_do_execbuffer.patch
+drm-nouveau-dispnv50-don-t-call-drm_atomic_get_crtc_state-in-prepare_fb.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
