5.10-stable patches

added patches:
	comedi-comedi_test-fix-possible-deletion-of-uninitialized-timers.patch
	x86-bugs-fix-use-of-possibly-uninit-value-in-amd_check_tsa_microcode.patch

diff --git a/queue-5.10/comedi-comedi_test-fix-possible-deletion-of-uninitialized-timers.patch b/queue-5.10/comedi-comedi_test-fix-possible-deletion-of-uninitialized-timers.patch
new file mode 100644 (file)
index 0000000..9d8090b
--- /dev/null
+++ b/queue-5.10/comedi-comedi_test-fix-possible-deletion-of-uninitialized-timers.patch
@@ -0,0 +1,42 @@
+From 1b98304c09a0192598d0767f1eb8c83d7e793091 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Tue, 8 Jul 2025 14:06:27 +0100
+Subject: comedi: comedi_test: Fix possible deletion of uninitialized timers
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 1b98304c09a0192598d0767f1eb8c83d7e793091 upstream.
+
+In `waveform_common_attach()`, the two timers `&devpriv->ai_timer` and
+`&devpriv->ao_timer` are initialized after the allocation of the device
+private data by `comedi_alloc_devpriv()` and the subdevices by
+`comedi_alloc_subdevices()`.  The function may return with an error
+between those function calls.  In that case, `waveform_detach()` will be
+called by the Comedi core to clean up.  The check that
+`waveform_detach()` uses to decide whether to delete the timers is
+incorrect.  It only checks that the device private data was allocated,
+but that does not guarantee that the timers were initialized.  It also
+needs to check that the subdevices were allocated.  Fix it.
+
+Fixes: 73e0e4dfed4c ("staging: comedi: comedi_test: fix timer lock-up")
+Cc: stable@vger.kernel.org # 6.15+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20250708130627.21743-1-abbotti@mev.co.uk
+[ file location from drivers/comedi to drivers/staging/comedi and timer_delete_sync() to del_timer_sync(). ]
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/comedi/drivers/comedi_test.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/comedi/drivers/comedi_test.c
++++ b/drivers/staging/comedi/drivers/comedi_test.c
+@@ -790,7 +790,7 @@ static void waveform_detach(struct comed
+ {
+       struct waveform_private *devpriv = dev->private;
+ 
+-      if (devpriv) {
++      if (devpriv && dev->n_subdevices) {
+               del_timer_sync(&devpriv->ai_timer);
+               del_timer_sync(&devpriv->ao_timer);
+       }

diff --git a/queue-5.10/series b/queue-5.10/series
index 3cd30d3904c5edee294182d1cc5378cd3e8811db..0e3f0dc7846031a33361bdb61ac481607e0edad1 100644 (file)
--- a/queue-5.10/series
+++ b/queue-5.10/series
@@ -67,3 +67,5 @@ e1000e-disregard-nvm-checksum-on-tgp-when-valid-checksum-bit-is-not-set.patch
 e1000e-ignore-uninitialized-checksum-word-on-tgp.patch
 gve-fix-stuck-tx-queue-for-dq-queue-format.patch
 nilfs2-reject-invalid-file-types-when-reading-inodes.patch
+x86-bugs-fix-use-of-possibly-uninit-value-in-amd_check_tsa_microcode.patch
+comedi-comedi_test-fix-possible-deletion-of-uninitialized-timers.patch

diff --git a/queue-5.10/x86-bugs-fix-use-of-possibly-uninit-value-in-amd_check_tsa_microcode.patch b/queue-5.10/x86-bugs-fix-use-of-possibly-uninit-value-in-amd_check_tsa_microcode.patch
new file mode 100644 (file)
index 0000000..fc0892f
--- /dev/null
+++ b/queue-5.10/x86-bugs-fix-use-of-possibly-uninit-value-in-amd_check_tsa_microcode.patch
@@ -0,0 +1,36 @@
+From mzhivich@akamai.com  Tue Jul 29 16:34:40 2025
+From: Michael Zhivich <mzhivich@akamai.com>
+Date: Wed, 23 Jul 2025 09:40:19 -0400
+Subject: x86/bugs: Fix use of possibly uninit value in amd_check_tsa_microcode()
+To: <stable@vger.kernel.org>, <bp@alien8.de>
+Cc: <tglx@linutronix.de>, <mingo@redhat.com>, <dave.hansen@linux.intel.com>, <x86@kernel.org>, <linux-kernel@vger.kernel.org>, Michael Zhivich <mzhivich@akamai.com>
+Message-ID: <20250723134019.2370983-1-mzhivich@akamai.com>
+
+From: Michael Zhivich <mzhivich@akamai.com>
+
+For kernels compiled with CONFIG_INIT_STACK_NONE=y, the value of __reserved
+field in zen_patch_rev union on the stack may be garbage.  If so, it will
+prevent correct microcode check when consulting p.ucode_rev, resulting in
+incorrect mitigation selection.
+
+This is a stable-only fix.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Michael Zhivich <mzhivich@akamai.com>
+Fixes: 78192f511f40 ("x86/bugs: Add a Transient Scheduler Attacks mitigation")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/amd.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -599,6 +599,8 @@ static bool amd_check_tsa_microcode(void
+       p.model         = c->x86_model;
+       p.ext_model     = c->x86_model >> 4;
+       p.stepping      = c->x86_stepping;
++      /* reserved bits are expected to be 0 in test below */
++      p.__reserved    = 0;
+ 
+       if (c->x86 == 0x19) {
+               switch (p.ucode_rev >> 8) {