From: Greg Kroah-Hartman Date: Mon, 13 May 2024 15:28:18 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.19.314~24 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8ec824350d9c22bf9e294ff73bd0ca1e7fe98f46;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch hwmon-pmbus-ucd9000-increase-delay-from-250-to-500us.patch net-fix-out-of-bounds-access-in-ops_init.patch regulator-core-fix-debugfs-creation-regression.patch --- diff --git a/queue-5.10/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch b/queue-5.10/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch new file mode 100644 index 00000000000..01953914fd9 --- /dev/null +++ b/queue-5.10/drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch @@ -0,0 +1,46 @@ +From a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c Mon Sep 17 00:00:00 2001 +From: Zack Rusin +Date: Thu, 25 Apr 2024 15:27:48 -0400 +Subject: drm/vmwgfx: Fix invalid reads in fence signaled events + +From: Zack Rusin + +commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream. + +Correctly set the length of the drm_event to the size of the structure +that's actually used. + +The length of the drm_event was set to the parent structure instead of +to the drm_vmw_event_fence which is supposed to be read. drm_read +uses the length parameter to copy the event to the user space thus +resuling in oob reads. + +Signed-off-by: Zack Rusin +Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action") +Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-23566 +Cc: David Airlie +CC: Daniel Vetter +Cc: Zack Rusin +Cc: Broadcom internal kernel review list +Cc: dri-devel@lists.freedesktop.org +Cc: linux-kernel@vger.kernel.org +Cc: # v3.4+ +Reviewed-by: Maaz Mombasawala +Reviewed-by: Martin Krastev +Link: https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.rusin@broadcom.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +@@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create + } + + event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED; +- event->event.base.length = sizeof(*event); ++ event->event.base.length = sizeof(event->event); + event->event.user_data = user_data; + + ret = drm_event_reserve_init(dev, file_priv, &event->base, &event->event.base); diff --git a/queue-5.10/hwmon-pmbus-ucd9000-increase-delay-from-250-to-500us.patch b/queue-5.10/hwmon-pmbus-ucd9000-increase-delay-from-250-to-500us.patch new file mode 100644 index 00000000000..4614ba9a450 --- /dev/null +++ b/queue-5.10/hwmon-pmbus-ucd9000-increase-delay-from-250-to-500us.patch @@ -0,0 +1,44 @@ +From 26e8383b116d0dbe74e28f86646563ab46d66d83 Mon Sep 17 00:00:00 2001 +From: Lakshmi Yadlapati +Date: Tue, 7 May 2024 14:46:03 -0500 +Subject: hwmon: (pmbus/ucd9000) Increase delay from 250 to 500us + +From: Lakshmi Yadlapati + +commit 26e8383b116d0dbe74e28f86646563ab46d66d83 upstream. + +Following the failure observed with a delay of 250us, experiments were +conducted with various delays. It was found that a delay of 350us +effectively mitigated the issue. + +To provide a more optimal solution while still allowing a margin for +stability, the delay is being adjusted to 500us. + +Signed-off-by: Lakshmi Yadlapati +Link: https://lore.kernel.org/r/20240507194603.1305750-1-lakshmiy@us.ibm.com +Fixes: 8d655e6523764 ("hwmon: (ucd90320) Add minimum delay between bus accesses") +Reviewed-by: Eddie James +Cc: stable@vger.kernel.org +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwmon/pmbus/ucd9000.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/hwmon/pmbus/ucd9000.c ++++ b/drivers/hwmon/pmbus/ucd9000.c +@@ -80,11 +80,11 @@ struct ucd9000_debugfs_entry { + * It has been observed that the UCD90320 randomly fails register access when + * doing another access right on the back of a register write. To mitigate this + * make sure that there is a minimum delay between a write access and the +- * following access. The 250us is based on experimental data. At a delay of +- * 200us the issue seems to go away. Add a bit of extra margin to allow for ++ * following access. The 500 is based on experimental data. At a delay of ++ * 350us the issue seems to go away. Add a bit of extra margin to allow for + * system to system differences. + */ +-#define UCD90320_WAIT_DELAY_US 250 ++#define UCD90320_WAIT_DELAY_US 500 + + static inline void ucd90320_wait(const struct ucd9000_data *data) + { diff --git a/queue-5.10/net-fix-out-of-bounds-access-in-ops_init.patch b/queue-5.10/net-fix-out-of-bounds-access-in-ops_init.patch new file mode 100644 index 00000000000..259e6dff939 --- /dev/null +++ b/queue-5.10/net-fix-out-of-bounds-access-in-ops_init.patch @@ -0,0 +1,66 @@ +From a26ff37e624d12e28077e5b24d2b264f62764ad6 Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo +Date: Thu, 2 May 2024 10:20:06 -0300 +Subject: net: fix out-of-bounds access in ops_init + +From: Thadeu Lima de Souza Cascardo + +commit a26ff37e624d12e28077e5b24d2b264f62764ad6 upstream. + +net_alloc_generic is called by net_alloc, which is called without any +locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It +is read twice, first to allocate an array, then to set s.len, which is +later used to limit the bounds of the array access. + +It is possible that the array is allocated and another thread is +registering a new pernet ops, increments max_gen_ptrs, which is then used +to set s.len with a larger than allocated length for the variable array. + +Fix it by reading max_gen_ptrs only once in net_alloc_generic. If +max_gen_ptrs is later incremented, it will be caught in net_assign_generic. + +Signed-off-by: Thadeu Lima de Souza Cascardo +Fixes: 073862ba5d24 ("netns: fix net_alloc_generic()") +Reviewed-by: Eric Dumazet +Reviewed-by: Kuniyuki Iwashima +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240502132006.3430840-1-cascardo@igalia.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + net/core/net_namespace.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/net/core/net_namespace.c ++++ b/net/core/net_namespace.c +@@ -86,12 +86,15 @@ u64 __net_gen_cookie(struct net *net) + + static struct net_generic *net_alloc_generic(void) + { ++ unsigned int gen_ptrs = READ_ONCE(max_gen_ptrs); ++ unsigned int generic_size; + struct net_generic *ng; +- unsigned int generic_size = offsetof(struct net_generic, ptr[max_gen_ptrs]); ++ ++ generic_size = offsetof(struct net_generic, ptr[gen_ptrs]); + + ng = kzalloc(generic_size, GFP_KERNEL); + if (ng) +- ng->s.len = max_gen_ptrs; ++ ng->s.len = gen_ptrs; + + return ng; + } +@@ -1241,7 +1244,11 @@ static int register_pernet_operations(st + if (error < 0) + return error; + *ops->id = error; +- max_gen_ptrs = max(max_gen_ptrs, *ops->id + 1); ++ /* This does not require READ_ONCE as writers already hold ++ * pernet_ops_rwsem. But WRITE_ONCE is needed to protect ++ * net_alloc_generic. ++ */ ++ WRITE_ONCE(max_gen_ptrs, max(max_gen_ptrs, *ops->id + 1)); + } + error = __register_pernet_operations(list, ops); + if (error) { diff --git a/queue-5.10/regulator-core-fix-debugfs-creation-regression.patch b/queue-5.10/regulator-core-fix-debugfs-creation-regression.patch new file mode 100644 index 00000000000..65de4136111 --- /dev/null +++ b/queue-5.10/regulator-core-fix-debugfs-creation-regression.patch @@ -0,0 +1,76 @@ +From 2a4b49bb58123bad6ec0e07b02845f74c23d5e04 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Thu, 9 May 2024 15:33:04 +0200 +Subject: regulator: core: fix debugfs creation regression + +From: Johan Hovold + +commit 2a4b49bb58123bad6ec0e07b02845f74c23d5e04 upstream. + +regulator_get() may sometimes be called more than once for the same +consumer device, something which before commit dbe954d8f163 ("regulator: +core: Avoid debugfs: Directory ... already present! error") resulted in +errors being logged. + +A couple of recent commits broke the handling of such cases so that +attributes are now erroneously created in the debugfs root directory the +second time a regulator is requested and the log is filled with errors +like: + + debugfs: File 'uA_load' in directory '/' already present! + debugfs: File 'min_uV' in directory '/' already present! + debugfs: File 'max_uV' in directory '/' already present! + debugfs: File 'constraint_flags' in directory '/' already present! + +on any further calls. + +Fixes: 2715bb11cfff ("regulator: core: Fix more error checking for debugfs_create_dir()") +Fixes: 08880713ceec ("regulator: core: Streamline debugfs operations") +Cc: stable@vger.kernel.org +Cc: Geert Uytterhoeven +Signed-off-by: Johan Hovold +Link: https://lore.kernel.org/r/20240509133304.8883-1-johan+linaro@kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + drivers/regulator/core.c | 27 ++++++++++++++++----------- + 1 file changed, 16 insertions(+), 11 deletions(-) + +--- a/drivers/regulator/core.c ++++ b/drivers/regulator/core.c +@@ -1749,19 +1749,24 @@ static struct regulator *create_regulato + } + } + +- if (err != -EEXIST) ++ if (err != -EEXIST) { + regulator->debugfs = debugfs_create_dir(supply_name, rdev->debugfs); +- if (IS_ERR(regulator->debugfs)) +- rdev_dbg(rdev, "Failed to create debugfs directory\n"); ++ if (IS_ERR(regulator->debugfs)) { ++ rdev_dbg(rdev, "Failed to create debugfs directory\n"); ++ regulator->debugfs = NULL; ++ } ++ } + +- debugfs_create_u32("uA_load", 0444, regulator->debugfs, +- ®ulator->uA_load); +- debugfs_create_u32("min_uV", 0444, regulator->debugfs, +- ®ulator->voltage[PM_SUSPEND_ON].min_uV); +- debugfs_create_u32("max_uV", 0444, regulator->debugfs, +- ®ulator->voltage[PM_SUSPEND_ON].max_uV); +- debugfs_create_file("constraint_flags", 0444, regulator->debugfs, +- regulator, &constraint_flags_fops); ++ if (regulator->debugfs) { ++ debugfs_create_u32("uA_load", 0444, regulator->debugfs, ++ ®ulator->uA_load); ++ debugfs_create_u32("min_uV", 0444, regulator->debugfs, ++ ®ulator->voltage[PM_SUSPEND_ON].min_uV); ++ debugfs_create_u32("max_uV", 0444, regulator->debugfs, ++ ®ulator->voltage[PM_SUSPEND_ON].max_uV); ++ debugfs_create_file("constraint_flags", 0444, regulator->debugfs, ++ regulator, &constraint_flags_fops); ++ } + + /* + * Check now if the regulator is an always on regulator - if diff --git a/queue-5.10/series b/queue-5.10/series index 4acc101526e..61e564d0f95 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -107,3 +107,7 @@ net-bcmgenet-synchronize-use-of-bcmgenet_set_rx_mode.patch asoc-tegra-fix-dspk-16-bit-playback.patch dyndbg-fix-old-bug_on-in-control-parser.patch mei-me-add-lunar-lake-point-m-did.patch +drm-vmwgfx-fix-invalid-reads-in-fence-signaled-events.patch +net-fix-out-of-bounds-access-in-ops_init.patch +hwmon-pmbus-ucd9000-increase-delay-from-250-to-500us.patch +regulator-core-fix-debugfs-creation-regression.patch