From: Greg Kroah-Hartman Date: Mon, 1 Apr 2024 13:12:08 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v6.7.12~47 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4f9c6fccfa5e24da7441c6a3aae2a026b98a8c21;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: drm-imx-parallel-display-remove-bus-flags-check-in-imx_pd_bridge_atomic_check.patch timers-move-clearing-of-base-timer_running-under-base-lock.patch x86-cpu-enable-stibp-on-amd-if-automatic-ibrs-is-enabled.patch --- diff --git a/queue-4.19/drm-imx-parallel-display-remove-bus-flags-check-in-imx_pd_bridge_atomic_check.patch b/queue-4.19/drm-imx-parallel-display-remove-bus-flags-check-in-imx_pd_bridge_atomic_check.patch new file mode 100644 index 00000000000..dc812b0cbb3 --- /dev/null +++ b/queue-4.19/drm-imx-parallel-display-remove-bus-flags-check-in-imx_pd_bridge_atomic_check.patch @@ -0,0 +1,63 @@ +From 6061806a863e8b65b109eb06a280041cc7525442 Mon Sep 17 00:00:00 2001 +From: Christoph Niedermaier +Date: Tue, 1 Feb 2022 12:36:43 +0100 +Subject: drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check() + +From: Christoph Niedermaier + +commit 6061806a863e8b65b109eb06a280041cc7525442 upstream. + +If display timings were read from the devicetree using +of_get_display_timing() and pixelclk-active is defined +there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is +automatically generated. Through the function +drm_bus_flags_from_videomode() e.g. called in the +panel-simple driver this flag got into the bus flags, +but then in imx_pd_bridge_atomic_check() the bus flag +check failed and will not initialize the display. The +original commit fe141cedc433 does not explain why this +check was introduced. So remove the bus flags check, +because it stops the initialization of the display with +valid bus flags. + +Fixes: fe141cedc433 ("drm/imx: pd: Use bus format/flags provided by the bridge when available") +Signed-off-by: Christoph Niedermaier +Cc: Marek Vasut +Cc: Boris Brezillon +Cc: Philipp Zabel +Cc: David Airlie +Cc: Daniel Vetter +Cc: Shawn Guo +Cc: Sascha Hauer +Cc: Pengutronix Kernel Team +Cc: Fabio Estevam +Cc: NXP Linux Team +Cc: linux-arm-kernel@lists.infradead.org +To: dri-devel@lists.freedesktop.org +Tested-by: Max Krummenacher +Acked-by: Boris Brezillon +Signed-off-by: Marek Vasut +Link: https://patchwork.freedesktop.org/patch/msgid/20220201113643.4638-1-cniedermaier@dh-electronics.com +Signed-off-by: Maarten Lankhorst +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/imx/parallel-display.c | 8 -------- + 1 file changed, 8 deletions(-) + +--- a/drivers/gpu/drm/imx/parallel-display.c ++++ b/drivers/gpu/drm/imx/parallel-display.c +@@ -235,14 +235,6 @@ static int imx_pd_bridge_atomic_check(st + if (!imx_pd_format_supported(bus_fmt)) + return -EINVAL; + +- if (bus_flags & +- ~(DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_DE_HIGH | +- DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE | +- DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)) { +- dev_warn(imxpd->dev, "invalid bus_flags (%x)\n", bus_flags); +- return -EINVAL; +- } +- + bridge_state->output_bus_cfg.flags = bus_flags; + bridge_state->input_bus_cfg.flags = bus_flags; + imx_crtc_state->bus_flags = bus_flags; diff --git a/queue-4.19/series b/queue-4.19/series index 0739159da37..05752c6b1a6 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -104,3 +104,6 @@ usb-dwc2-host-fix-isoc-flow-in-ddma-mode.patch usb-dwc2-gadget-lpm-flow-fix.patch usb-udc-remove-warning-when-queue-disabled-ep.patch scsi-qla2xxx-fix-command-flush-on-cable-pull.patch +x86-cpu-enable-stibp-on-amd-if-automatic-ibrs-is-enabled.patch +timers-move-clearing-of-base-timer_running-under-base-lock.patch +drm-imx-parallel-display-remove-bus-flags-check-in-imx_pd_bridge_atomic_check.patch diff --git a/queue-4.19/timers-move-clearing-of-base-timer_running-under-base-lock.patch b/queue-4.19/timers-move-clearing-of-base-timer_running-under-base-lock.patch new file mode 100644 index 00000000000..7af8f7b363d --- /dev/null +++ b/queue-4.19/timers-move-clearing-of-base-timer_running-under-base-lock.patch @@ -0,0 +1,84 @@ +From bb7262b295472eb6858b5c49893954794027cd84 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Sun, 6 Dec 2020 22:40:07 +0100 +Subject: timers: Move clearing of base::timer_running under base:: Lock + +From: Thomas Gleixner + +commit bb7262b295472eb6858b5c49893954794027cd84 upstream. + +syzbot reported KCSAN data races vs. timer_base::timer_running being set to +NULL without holding base::lock in expire_timers(). + +This looks innocent and most reads are clearly not problematic, but +Frederic identified an issue which is: + + int data = 0; + + void timer_func(struct timer_list *t) + { + data = 1; + } + + CPU 0 CPU 1 + ------------------------------ -------------------------- + base = lock_timer_base(timer, &flags); raw_spin_unlock(&base->lock); + if (base->running_timer != timer) call_timer_fn(timer, fn, baseclk); + ret = detach_if_pending(timer, base, true); base->running_timer = NULL; + raw_spin_unlock_irqrestore(&base->lock, flags); raw_spin_lock(&base->lock); + + x = data; + +If the timer has previously executed on CPU 1 and then CPU 0 can observe +base->running_timer == NULL and returns, assuming the timer has completed, +but it's not guaranteed on all architectures. The comment for +del_timer_sync() makes that guarantee. Moving the assignment under +base->lock prevents this. + +For non-RT kernel it's performance wise completely irrelevant whether the +store happens before or after taking the lock. For an RT kernel moving the +store under the lock requires an extra unlock/lock pair in the case that +there is a waiter for the timer, but that's not the end of the world. + +Reported-by: syzbot+aa7c2385d46c5eba0b89@syzkaller.appspotmail.com +Reported-by: syzbot+abea4558531bae1ba9fe@syzkaller.appspotmail.com +Fixes: 030dcdd197d7 ("timers: Prepare support for PREEMPT_RT") +Signed-off-by: Thomas Gleixner +Tested-by: Sebastian Andrzej Siewior +Link: https://lore.kernel.org/r/87lfea7gw8.fsf@nanos.tec.linutronix.de +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/time/timer.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/kernel/time/timer.c ++++ b/kernel/time/timer.c +@@ -1304,8 +1304,10 @@ static inline void timer_base_unlock_exp + static void timer_sync_wait_running(struct timer_base *base) + { + if (atomic_read(&base->timer_waiters)) { ++ raw_spin_unlock_irq(&base->lock); + spin_unlock(&base->expiry_lock); + spin_lock(&base->expiry_lock); ++ raw_spin_lock_irq(&base->lock); + } + } + +@@ -1490,14 +1492,14 @@ static void expire_timers(struct timer_b + if (timer->flags & TIMER_IRQSAFE) { + raw_spin_unlock(&base->lock); + call_timer_fn(timer, fn, baseclk); +- base->running_timer = NULL; + raw_spin_lock(&base->lock); ++ base->running_timer = NULL; + } else { + raw_spin_unlock_irq(&base->lock); + call_timer_fn(timer, fn, baseclk); ++ raw_spin_lock_irq(&base->lock); + base->running_timer = NULL; + timer_sync_wait_running(base); +- raw_spin_lock_irq(&base->lock); + } + } + } diff --git a/queue-4.19/x86-cpu-enable-stibp-on-amd-if-automatic-ibrs-is-enabled.patch b/queue-4.19/x86-cpu-enable-stibp-on-amd-if-automatic-ibrs-is-enabled.patch new file mode 100644 index 00000000000..103731f74c4 --- /dev/null +++ b/queue-4.19/x86-cpu-enable-stibp-on-amd-if-automatic-ibrs-is-enabled.patch @@ -0,0 +1,91 @@ +From fd470a8beed88440b160d690344fbae05a0b9b1b Mon Sep 17 00:00:00 2001 +From: Kim Phillips +Date: Thu, 20 Jul 2023 14:47:27 -0500 +Subject: x86/cpu: Enable STIBP on AMD if Automatic IBRS is enabled + +From: Kim Phillips + +commit fd470a8beed88440b160d690344fbae05a0b9b1b upstream. + +Unlike Intel's Enhanced IBRS feature, AMD's Automatic IBRS does not +provide protection to processes running at CPL3/user mode, see section +"Extended Feature Enable Register (EFER)" in the APM v2 at +https://bugzilla.kernel.org/attachment.cgi?id=304652 + +Explicitly enable STIBP to protect against cross-thread CPL3 +branch target injections on systems with Automatic IBRS enabled. + +Also update the relevant documentation. + +Fixes: e7862eda309e ("x86/cpu: Support AMD Automatic IBRS") +Reported-by: Tom Lendacky +Signed-off-by: Kim Phillips +Signed-off-by: Borislav Petkov (AMD) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230720194727.67022-1-kim.phillips@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/admin-guide/hw-vuln/spectre.rst | 11 +++++++---- + arch/x86/kernel/cpu/bugs.c | 15 +++++++++------ + 2 files changed, 16 insertions(+), 10 deletions(-) + +--- a/Documentation/admin-guide/hw-vuln/spectre.rst ++++ b/Documentation/admin-guide/hw-vuln/spectre.rst +@@ -484,11 +484,14 @@ Spectre variant 2 + + Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at + boot, by setting the IBRS bit, and they're automatically protected against +- Spectre v2 variant attacks, including cross-thread branch target injections +- on SMT systems (STIBP). In other words, eIBRS enables STIBP too. ++ Spectre v2 variant attacks. + +- Legacy IBRS systems clear the IBRS bit on exit to userspace and +- therefore explicitly enable STIBP for that ++ On Intel's enhanced IBRS systems, this includes cross-thread branch target ++ injections on SMT systems (STIBP). In other words, Intel eIBRS enables ++ STIBP, too. ++ ++ AMD Automatic IBRS does not protect userspace, and Legacy IBRS systems clear ++ the IBRS bit on exit to userspace, therefore both explicitly enable STIBP. + + The retpoline mitigation is turned on by default on vulnerable + CPUs. It can be forced on or off by the administrator +--- a/arch/x86/kernel/cpu/bugs.c ++++ b/arch/x86/kernel/cpu/bugs.c +@@ -1153,19 +1153,21 @@ spectre_v2_user_select_mitigation(void) + } + + /* +- * If no STIBP, enhanced IBRS is enabled, or SMT impossible, STIBP ++ * If no STIBP, Intel enhanced IBRS is enabled, or SMT impossible, STIBP + * is not required. + * +- * Enhanced IBRS also protects against cross-thread branch target ++ * Intel's Enhanced IBRS also protects against cross-thread branch target + * injection in user-mode as the IBRS bit remains always set which + * implicitly enables cross-thread protections. However, in legacy IBRS + * mode, the IBRS bit is set only on kernel entry and cleared on return +- * to userspace. This disables the implicit cross-thread protection, +- * so allow for STIBP to be selected in that case. ++ * to userspace. AMD Automatic IBRS also does not protect userspace. ++ * These modes therefore disable the implicit cross-thread protection, ++ * so allow for STIBP to be selected in those cases. + */ + if (!boot_cpu_has(X86_FEATURE_STIBP) || + !smt_possible || +- spectre_v2_in_eibrs_mode(spectre_v2_enabled)) ++ (spectre_v2_in_eibrs_mode(spectre_v2_enabled) && ++ !boot_cpu_has(X86_FEATURE_AUTOIBRS))) + return; + + /* +@@ -2221,7 +2223,8 @@ static ssize_t mmio_stale_data_show_stat + + static char *stibp_state(void) + { +- if (spectre_v2_in_eibrs_mode(spectre_v2_enabled)) ++ if (spectre_v2_in_eibrs_mode(spectre_v2_enabled) && ++ !boot_cpu_has(X86_FEATURE_AUTOIBRS)) + return ""; + + switch (spectre_v2_user_stibp) {