From: Greg Kroah-Hartman Date: Mon, 5 Jan 2026 13:35:08 +0000 (+0100) Subject: 6.1-stable patches X-Git-Tag: v6.12.64~17 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=132e4a704897a5d8eb0dcd3f42b33555c122675d;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: drm-i915-gem-zero-initialize-the-eb.vma-array-in-i915_gem_do_execbuffer.patch drm-mediatek-fix-device-node-reference-leak-in-mtk_dp_dt_parse.patch drm-mgag200-fix-big-endian-support.patch drm-msm-a6xx-fix-out-of-bound-io-access-in-a6xx_get_gmu_registers.patch drm-nouveau-dispnv50-don-t-call-drm_atomic_get_crtc_state-in-prepare_fb.patch drm-ttm-avoid-null-pointer-deref-for-evicted-bos.patch --- diff --git a/queue-6.1/drm-i915-gem-zero-initialize-the-eb.vma-array-in-i915_gem_do_execbuffer.patch b/queue-6.1/drm-i915-gem-zero-initialize-the-eb.vma-array-in-i915_gem_do_execbuffer.patch new file mode 100644 index 0000000000..944990e00b --- /dev/null +++ b/queue-6.1/drm-i915-gem-zero-initialize-the-eb.vma-array-in-i915_gem_do_execbuffer.patch @@ -0,0 +1,137 @@ +From 4fe2bd195435e71c117983d87f278112c5ab364c Mon Sep 17 00:00:00 2001 +From: Krzysztof Niemiec +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 + +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 +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 +Reviewed-by: Janusz Krzysztofik +Reviewed-by: Krzysztof Karas +Reviewed-by: Andi Shyti +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/20251216180900.54294-2-krzysztof.niemiec@intel.com +(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + 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) { diff --git a/queue-6.1/drm-mediatek-fix-device-node-reference-leak-in-mtk_dp_dt_parse.patch b/queue-6.1/drm-mediatek-fix-device-node-reference-leak-in-mtk_dp_dt_parse.patch new file mode 100644 index 0000000000..965a208fed --- /dev/null +++ b/queue-6.1/drm-mediatek-fix-device-node-reference-leak-in-mtk_dp_dt_parse.patch @@ -0,0 +1,41 @@ +From a846505a193d7492ad3531e33cacfca31e4bcdd1 Mon Sep 17 00:00:00 2001 +From: Miaoqian Lin +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 + +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 +Reviewed-by: Markus Schneider-Pargmann +Reviewed-by: CK Hu +Link: https://patchwork.kernel.org/project/dri-devel/patch/20251029072307.10955-1-linmq006@gmail.com/ +Signed-off-by: Chun-Kuang Hu +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/drm-mgag200-fix-big-endian-support.patch b/queue-6.1/drm-mgag200-fix-big-endian-support.patch new file mode 100644 index 0000000000..55d224989e --- /dev/null +++ b/queue-6.1/drm-mgag200-fix-big-endian-support.patch @@ -0,0 +1,69 @@ +From 6cb31fba137d45e682ce455b8ea364f44d5d4f98 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ren=C3=A9=20Rebe?= +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 + +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 +Cc: stable@kernel.org +Reviewed-by: Thomas Zimmermann +Signed-off-by: Thomas Zimmermann +Link: https://patch.msgid.link/20251208.141827.965103015954471168.rene@exactco.de +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.1/drm-msm-a6xx-fix-out-of-bound-io-access-in-a6xx_get_gmu_registers.patch b/queue-6.1/drm-msm-a6xx-fix-out-of-bound-io-access-in-a6xx_get_gmu_registers.patch new file mode 100644 index 0000000000..2ba665dd8f --- /dev/null +++ b/queue-6.1/drm-msm-a6xx-fix-out-of-bound-io-access-in-a6xx_get_gmu_registers.patch @@ -0,0 +1,35 @@ +From 779b68a5bf2764c8ed3aa800e41ba0d5d007e1e7 Mon Sep 17 00:00:00 2001 +From: Akhil P Oommen +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 + +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 +Reviewed-by: Konrad Dybcio +Patchwork: https://patchwork.freedesktop.org/patch/688993/ +Message-ID: <20251118-kaana-gpu-support-v4-1-86eeb8e93fb6@oss.qualcomm.com> +Signed-off-by: Rob Clark +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.1/drm-nouveau-dispnv50-don-t-call-drm_atomic_get_crtc_state-in-prepare_fb.patch b/queue-6.1/drm-nouveau-dispnv50-don-t-call-drm_atomic_get_crtc_state-in-prepare_fb.patch new file mode 100644 index 0000000000..7102582dfc --- /dev/null +++ b/queue-6.1/drm-nouveau-dispnv50-don-t-call-drm_atomic_get_crtc_state-in-prepare_fb.patch @@ -0,0 +1,63 @@ +From 560271e10b2c86e95ea35afa9e79822e4847f07a Mon Sep 17 00:00:00 2001 +From: Lyude Paul +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 + +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 +Reviewed-by: Dave Airlie +Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files") +Cc: # v4.18+ +Link: https://patch.msgid.link/20251211190256.396742-1-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-6.1/drm-ttm-avoid-null-pointer-deref-for-evicted-bos.patch b/queue-6.1/drm-ttm-avoid-null-pointer-deref-for-evicted-bos.patch new file mode 100644 index 0000000000..e7ea7c02dd --- /dev/null +++ b/queue-6.1/drm-ttm-avoid-null-pointer-deref-for-evicted-bos.patch @@ -0,0 +1,56 @@ +From 491adc6a0f9903c32b05f284df1148de39e8e644 Mon Sep 17 00:00:00 2001 +From: Simon Richter +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 + +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 +Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6271 +Signed-off-by: Simon Richter +Reviewed-by: Matthew Brost +Reviewed-by: Shuicheng Lin +Reviewed-by: Christian König +Signed-off-by: Matthew Brost +Link: https://patch.msgid.link/20251013161241.709916-1-Simon.Richter@hogyros.de +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/series b/queue-6.1/series index 0bec1f664c..6d9a38b011 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -503,3 +503,9 @@ nfsd-drop-the-client-reference-in-client_states_open.patch 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