--- /dev/null
+From 3179a5f7f86bcc3acd5d6fb2a29f891ef5615852 Mon Sep 17 00:00:00 2001
+From: Li Chen <chenl311@chinatelecom.cn>
+Date: Mon, 17 Nov 2025 13:34:07 +0800
+Subject: block: rate-limit capacity change info log
+
+From: Li Chen <chenl311@chinatelecom.cn>
+
+commit 3179a5f7f86bcc3acd5d6fb2a29f891ef5615852 upstream.
+
+loop devices under heavy stress-ng loop streessor can trigger many
+capacity change events in a short time. Each event prints an info
+message from set_capacity_and_notify(), flooding the console and
+contributing to soft lockups on slow consoles.
+
+Switch the printk in set_capacity_and_notify() to
+pr_info_ratelimited() so frequent capacity changes do not spam
+the log while still reporting occasional changes.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Li Chen <chenl311@chinatelecom.cn>
+Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/genhd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/block/genhd.c
++++ b/block/genhd.c
+@@ -83,7 +83,7 @@ bool set_capacity_and_notify(struct gend
+ (disk->flags & GENHD_FL_HIDDEN))
+ return false;
+
+- pr_info("%s: detected capacity change from %lld to %lld\n",
++ pr_info_ratelimited("%s: detected capacity change from %lld to %lld\n",
+ disk->disk_name, capacity, size);
+
+ /*
--- /dev/null
+From 82d20481024cbae2ea87fe8b86d12961bfda7169 Mon Sep 17 00:00:00 2001
+From: Rene Rebe <rene@exactco.de>
+Date: Fri, 14 Nov 2025 14:41:27 +0100
+Subject: floppy: fix for PAGE_SIZE != 4KB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Rene Rebe <rene@exactco.de>
+
+commit 82d20481024cbae2ea87fe8b86d12961bfda7169 upstream.
+
+For years I wondered why the floppy driver does not just work on
+sparc64, e.g:
+
+root@SUNW_375_0066:# disktype /dev/fd0
+disktype: Can't open /dev/fd0: No such device or address
+
+[ 525.341906] disktype: attempt to access beyond end of device
+fd0: rw=0, sector=0, nr_sectors = 16 limit=8
+[ 525.341991] floppy: error 10 while reading block 0
+
+Turns out floppy.c __floppy_read_block_0 tries to read one page for
+the first test read to determine the disk size and thus fails if that
+is greater than 4k. Adjust minimum MAX_DISK_SIZE to PAGE_SIZE to fix
+floppy on sparc64 and likely all other PAGE_SIZE != 4KB configs.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: René Rebe <rene@exactco.de>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/block/floppy.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/block/floppy.c
++++ b/drivers/block/floppy.c
+@@ -331,7 +331,7 @@ static bool initialized;
+ * This default is used whenever the current disk size is unknown.
+ * [Now it is rather a minimum]
+ */
+-#define MAX_DISK_SIZE 4 /* 3984 */
++#define MAX_DISK_SIZE (PAGE_SIZE / 1024)
+
+ /*
+ * globals used by 'result()'
--- /dev/null
+From 801f614ba263cb37624982b27b4c82f3c3c597a9 Mon Sep 17 00:00:00 2001
+From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
+Date: Thu, 18 Sep 2025 13:35:24 +0300
+Subject: fs/ntfs3: fix mount failure for sparse runs in run_unpack()
+
+From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
+
+commit 801f614ba263cb37624982b27b4c82f3c3c597a9 upstream.
+
+Some NTFS volumes failed to mount because sparse data runs were not
+handled correctly during runlist unpacking. The code performed arithmetic
+on the special SPARSE_LCN64 marker, leading to invalid LCN values and
+mount errors.
+
+Add an explicit check for the case described above, marking the run as
+sparse without applying arithmetic.
+
+Fixes: 736fc7bf5f68 ("fs: ntfs3: Fix integer overflow in run_unpack()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ntfs3/run.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/ntfs3/run.c
++++ b/fs/ntfs3/run.c
+@@ -984,8 +984,12 @@ int run_unpack(struct runs_tree *run, st
+ if (!dlcn)
+ return -EINVAL;
+
+- if (check_add_overflow(prev_lcn, dlcn, &lcn))
++ /* Check special combination: 0 + SPARSE_LCN64. */
++ if (!prev_lcn && dlcn == SPARSE_LCN64) {
++ lcn = SPARSE_LCN64;
++ } else if (check_add_overflow(prev_lcn, dlcn, &lcn)) {
+ return -EINVAL;
++ }
+ prev_lcn = lcn;
+ } else {
+ /* The size of 'dlcn' can't be > 8. */
--- /dev/null
+From b14fad555302a2104948feaff70503b64c80ac01 Mon Sep 17 00:00:00 2001
+From: Prithvi Tambewagh <activprithvi@gmail.com>
+Date: Thu, 25 Dec 2025 12:58:29 +0530
+Subject: io_uring: fix filename leak in __io_openat_prep()
+
+From: Prithvi Tambewagh <activprithvi@gmail.com>
+
+commit b14fad555302a2104948feaff70503b64c80ac01 upstream.
+
+ __io_openat_prep() allocates a struct filename using getname(). However,
+for the condition of the file being installed in the fixed file table as
+well as having O_CLOEXEC flag set, the function returns early. At that
+point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this,
+the memory for the newly allocated struct filename is not cleaned up,
+causing a memory leak.
+
+Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the
+successful getname() call, so that when the request is torn down, the
+filename will be cleaned up, along with other resources needing cleanup.
+
+Reported-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f
+Tested-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
+Fixes: b9445598d8c6 ("io_uring: openat directly into fixed fd table")
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/openclose.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/io_uring/openclose.c
++++ b/io_uring/openclose.c
+@@ -70,13 +70,13 @@ static int __io_openat_prep(struct io_ki
+ open->filename = NULL;
+ return ret;
+ }
++ req->flags |= REQ_F_NEED_CLEANUP;
+
+ open->file_slot = READ_ONCE(sqe->file_index);
+ if (open->file_slot && (open->how.flags & O_CLOEXEC))
+ return -EINVAL;
+
+ open->nofile = rlimit(RLIMIT_NOFILE);
+- req->flags |= REQ_F_NEED_CLEANUP;
+ if (io_openat_force_async(open))
+ req->flags |= REQ_F_FORCE_ASYNC;
+ return 0;
--- /dev/null
+From f3f9f42232dee596d15491ca3f611d02174db49c Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian@huaweicloud.com>
+Date: Fri, 11 Oct 2024 22:38:53 +0800
+Subject: kallsyms: Fix wrong "big" kernel symbol type read from procfs
+
+From: Zheng Yejian <zhengyejian@huaweicloud.com>
+
+commit f3f9f42232dee596d15491ca3f611d02174db49c upstream.
+
+Currently when the length of a symbol is longer than 0x7f characters,
+its type shown in /proc/kallsyms can be incorrect.
+
+I found this issue when reading the code, but it can be reproduced by
+following steps:
+
+ 1. Define a function which symbol length is 130 characters:
+
+ #define X13(x) x##x##x##x##x##x##x##x##x##x##x##x##x
+ static noinline void X13(x123456789)(void)
+ {
+ printk("hello world\n");
+ }
+
+ 2. The type in vmlinux is 't':
+
+ $ nm vmlinux | grep x123456
+ ffffffff816290f0 t x123456789x123456789x123456789x12[...]
+
+ 3. Then boot the kernel, the type shown in /proc/kallsyms becomes 'g'
+ instead of the expected 't':
+
+ # cat /proc/kallsyms | grep x123456
+ ffffffff816290f0 g x123456789x123456789x123456789x12[...]
+
+The root cause is that, after commit 73bbb94466fd ("kallsyms: support
+"big" kernel symbols"), ULEB128 was used to encode symbol name length.
+That is, for "big" kernel symbols of which name length is longer than
+0x7f characters, the length info is encoded into 2 bytes.
+
+kallsyms_get_symbol_type() expects to read the first char of the
+symbol name which indicates the symbol type. However, due to the
+"big" symbol case not being handled, the symbol type read from
+/proc/kallsyms may be wrong, so handle it properly.
+
+Cc: stable@vger.kernel.org
+Fixes: 73bbb94466fd ("kallsyms: support "big" kernel symbols")
+Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
+Acked-by: Gary Guo <gary@garyguo.net>
+Link: https://patch.msgid.link/20241011143853.3022643-1-zhengyejian@huaweicloud.com
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/kallsyms.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/kernel/kallsyms.c
++++ b/kernel/kallsyms.c
+@@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(uns
+ {
+ /*
+ * Get just the first code, look it up in the token table,
+- * and return the first char from this token.
++ * and return the first char from this token. If MSB of length
++ * is 1, it is a "big" symbol, so needs an additional byte.
+ */
++ if (kallsyms_names[off] & 0x80)
++ off++;
+ return kallsyms_token_table[kallsyms_token_index[kallsyms_names[off + 1]]];
+ }
+
--- /dev/null
+From 62cd5d480b9762ce70d720a81fa5b373052ae05f Mon Sep 17 00:00:00 2001
+From: Jarkko Sakkinen <jarkko@kernel.org>
+Date: Sat, 18 Oct 2025 13:30:36 +0300
+Subject: KEYS: trusted: Fix a memory leak in tpm2_load_cmd
+
+From: Jarkko Sakkinen <jarkko@kernel.org>
+
+commit 62cd5d480b9762ce70d720a81fa5b373052ae05f upstream.
+
+'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode'
+but it is not freed in the failure paths. Address this by wrapping the blob
+into with a cleanup helper.
+
+Cc: stable@vger.kernel.org # v5.13+
+Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ security/keys/trusted-keys/trusted_tpm2.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/security/keys/trusted-keys/trusted_tpm2.c
++++ b/security/keys/trusted-keys/trusted_tpm2.c
+@@ -387,6 +387,7 @@ static int tpm2_load_cmd(struct tpm_chip
+ struct trusted_key_options *options,
+ u32 *blob_handle)
+ {
++ u8 *blob_ref __free(kfree) = NULL;
+ struct tpm_buf buf;
+ unsigned int private_len;
+ unsigned int public_len;
+@@ -400,6 +401,9 @@ static int tpm2_load_cmd(struct tpm_chip
+ /* old form */
+ blob = payload->blob;
+ payload->old_format = 1;
++ } else {
++ /* Bind for cleanup: */
++ blob_ref = blob;
+ }
+
+ /* new format carries keyhandle but old format doesn't */
+@@ -464,8 +468,6 @@ static int tpm2_load_cmd(struct tpm_chip
+ (__be32 *) &buf.data[TPM_HEADER_SIZE]);
+
+ out:
+- if (blob != payload->blob)
+- kfree(blob);
+ tpm_buf_destroy(&buf);
+
+ if (rc > 0)
--- /dev/null
+From d3042cbe84a060b4df764eb6c5300bbe20d125ca Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Wed, 3 Dec 2025 18:09:24 -0500
+Subject: ktest.pl: Fix uninitialized var in config-bisect.pl
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit d3042cbe84a060b4df764eb6c5300bbe20d125ca upstream.
+
+The error path of copying the old config used the wrong variable in the
+error message:
+
+ $ mkdir /tmp/build
+ $ ./tools/testing/ktest/config-bisect.pl -b /tmp/build config-good /tmp/config-bad
+ $ chmod 0 /tmp/build
+ $ ./tools/testing/ktest/config-bisect.pl -b /tmp/build config-good /tmp/config-bad good
+ cp /tmp/build//.config config-good.tmp ... [0 seconds] FAILED!
+ Use of uninitialized value $config in concatenation (.) or string at ./tools/testing/ktest/config-bisect.pl line 744.
+ failed to copy to config-good.tmp
+
+When it should have shown:
+
+ failed to copy /tmp/build//.config to config-good.tmp
+
+Cc: stable@vger.kernel.org
+Cc: John 'Warthog9' Hawley <warthog9@kernel.org>
+Fixes: 0f0db065999cf ("ktest: Add standalone config-bisect.pl program")
+Link: https://patch.msgid.link/20251203180924.6862bd26@gandalf.local.home
+Reported-by: "John W. Krahn" <jwkrahn@shaw.ca>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/ktest/config-bisect.pl | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/tools/testing/ktest/config-bisect.pl
++++ b/tools/testing/ktest/config-bisect.pl
+@@ -741,9 +741,9 @@ if ($start) {
+ die "Can not find file $bad\n";
+ }
+ if ($val eq "good") {
+- run_command "cp $output_config $good" or die "failed to copy $config to $good\n";
++ run_command "cp $output_config $good" or die "failed to copy $output_config to $good\n";
+ } elsif ($val eq "bad") {
+- run_command "cp $output_config $bad" or die "failed to copy $config to $bad\n";
++ run_command "cp $output_config $bad" or die "failed to copy $output_config to $bad\n";
+ }
+ }
+
--- /dev/null
+From 2f22115709fc7ebcfa40af3367a508fbbd2f71e9 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Sun, 2 Nov 2025 15:42:04 -0800
+Subject: lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit 2f22115709fc7ebcfa40af3367a508fbbd2f71e9 upstream.
+
+In the C code, the 'inc' argument to the assembly functions
+blake2s_compress_ssse3() and blake2s_compress_avx512() is declared with
+type u32, matching blake2s_compress(). The assembly code then reads it
+from the 64-bit %rcx. However, the ABI doesn't guarantee zero-extension
+to 64 bits, nor do gcc or clang guarantee it. Therefore, fix these
+functions to read this argument from the 32-bit %ecx.
+
+In theory, this bug could have caused the wrong 'inc' value to be used,
+causing incorrect BLAKE2s hashes. In practice, probably not: I've fixed
+essentially this same bug in many other assembly files too, but there's
+never been a real report of it having caused a problem. In x86_64, all
+writes to 32-bit registers are zero-extended to 64 bits. That results
+in zero-extension in nearly all situations. I've only been able to
+demonstrate a lack of zero-extension with a somewhat contrived example
+involving truncation, e.g. when the C code has a u64 variable holding
+0x1234567800000040 and passes it as a u32 expecting it to be truncated
+to 0x40 (64). But that's not what the real code does, of course.
+
+Fixes: ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")
+Cc: stable@vger.kernel.org
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20251102234209.62133-2-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/crypto/blake2s-core.S | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/crypto/blake2s-core.S
++++ b/arch/x86/crypto/blake2s-core.S
+@@ -54,7 +54,7 @@ SYM_FUNC_START(blake2s_compress_ssse3)
+ movdqa ROT16(%rip),%xmm12
+ movdqa ROR328(%rip),%xmm13
+ movdqu 0x20(%rdi),%xmm14
+- movq %rcx,%xmm15
++ movd %ecx,%xmm15
+ leaq SIGMA+0xa0(%rip),%r8
+ jmp .Lbeginofloop
+ .align 32
+@@ -179,7 +179,7 @@ SYM_FUNC_START(blake2s_compress_avx512)
+ vmovdqu (%rdi),%xmm0
+ vmovdqu 0x10(%rdi),%xmm1
+ vmovdqu 0x20(%rdi),%xmm4
+- vmovq %rcx,%xmm5
++ vmovd %ecx,%xmm5
+ vmovdqa IV(%rip),%xmm14
+ vmovdqa IV+16(%rip),%xmm15
+ jmp .Lblake2s_compress_avx512_mainloop
--- /dev/null
+From b1f856b1727c2eaa4be2c6d7cd7a8ed052bbeb87 Mon Sep 17 00:00:00 2001
+From: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
+Date: Fri, 14 Nov 2025 13:58:24 +0530
+Subject: mmc: sdhci-msm: Avoid early clock doubling during HS400 transition
+
+From: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
+
+commit b1f856b1727c2eaa4be2c6d7cd7a8ed052bbeb87 upstream.
+
+According to the hardware programming guide, the clock frequency must
+remain below 52MHz during the transition to HS400 mode.
+
+However,in the current implementation, the timing is set to HS400 (a
+DDR mode) before adjusting the clock. This causes the clock to double
+prematurely to 104MHz during the transition phase, violating the
+specification and potentially resulting in CRC errors or CMD timeouts.
+
+This change ensures that clock doubling is avoided during intermediate
+transitions and is applied only when the card requires a 200MHz clock
+for HS400 operation.
+
+Signed-off-by: Sarthak Garg <sarthak.garg@oss.qualcomm.com>
+Reviewed-by: Bjorn Andersson <andersson@kernel.org>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-msm.c | 27 +++++++++++++++------------
+ 1 file changed, 15 insertions(+), 12 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-msm.c
++++ b/drivers/mmc/host/sdhci-msm.c
+@@ -344,41 +344,43 @@ static void sdhci_msm_v5_variant_writel_
+ writel_relaxed(val, host->ioaddr + offset);
+ }
+
+-static unsigned int msm_get_clock_mult_for_bus_mode(struct sdhci_host *host)
++static unsigned int msm_get_clock_mult_for_bus_mode(struct sdhci_host *host,
++ unsigned int clock,
++ unsigned int timing)
+ {
+- struct mmc_ios ios = host->mmc->ios;
+ /*
+ * The SDHC requires internal clock frequency to be double the
+ * actual clock that will be set for DDR mode. The controller
+ * uses the faster clock(100/400MHz) for some of its parts and
+ * send the actual required clock (50/200MHz) to the card.
+ */
+- if (ios.timing == MMC_TIMING_UHS_DDR50 ||
+- ios.timing == MMC_TIMING_MMC_DDR52 ||
+- ios.timing == MMC_TIMING_MMC_HS400 ||
++ if (timing == MMC_TIMING_UHS_DDR50 ||
++ timing == MMC_TIMING_MMC_DDR52 ||
++ (timing == MMC_TIMING_MMC_HS400 &&
++ clock == MMC_HS200_MAX_DTR) ||
+ host->flags & SDHCI_HS400_TUNING)
+ return 2;
+ return 1;
+ }
+
+ static void msm_set_clock_rate_for_bus_mode(struct sdhci_host *host,
+- unsigned int clock)
++ unsigned int clock,
++ unsigned int timing)
+ {
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+- struct mmc_ios curr_ios = host->mmc->ios;
+ struct clk *core_clk = msm_host->bulk_clks[0].clk;
+ unsigned long achieved_rate;
+ unsigned int desired_rate;
+ unsigned int mult;
+ int rc;
+
+- mult = msm_get_clock_mult_for_bus_mode(host);
++ mult = msm_get_clock_mult_for_bus_mode(host, clock, timing);
+ desired_rate = clock * mult;
+ rc = dev_pm_opp_set_rate(mmc_dev(host->mmc), desired_rate);
+ if (rc) {
+ pr_err("%s: Failed to set clock at rate %u at timing %d\n",
+- mmc_hostname(host->mmc), desired_rate, curr_ios.timing);
++ mmc_hostname(host->mmc), desired_rate, timing);
+ return;
+ }
+
+@@ -397,7 +399,7 @@ static void msm_set_clock_rate_for_bus_m
+ msm_host->clk_rate = desired_rate;
+
+ pr_debug("%s: Setting clock at rate %lu at timing %d\n",
+- mmc_hostname(host->mmc), achieved_rate, curr_ios.timing);
++ mmc_hostname(host->mmc), achieved_rate, timing);
+ }
+
+ /* Platform specific tuning */
+@@ -1239,7 +1241,7 @@ static int sdhci_msm_execute_tuning(stru
+ */
+ if (host->flags & SDHCI_HS400_TUNING) {
+ sdhci_msm_hc_select_mode(host);
+- msm_set_clock_rate_for_bus_mode(host, ios.clock);
++ msm_set_clock_rate_for_bus_mode(host, ios.clock, ios.timing);
+ host->flags &= ~SDHCI_HS400_TUNING;
+ }
+
+@@ -1864,6 +1866,7 @@ static void sdhci_msm_set_clock(struct s
+ {
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
++ struct mmc_ios ios = host->mmc->ios;
+
+ if (!clock) {
+ host->mmc->actual_clock = msm_host->clk_rate = 0;
+@@ -1872,7 +1875,7 @@ static void sdhci_msm_set_clock(struct s
+
+ sdhci_msm_hc_select_mode(host);
+
+- msm_set_clock_rate_for_bus_mode(host, clock);
++ msm_set_clock_rate_for_bus_mode(host, ios.clock, ios.timing);
+ out:
+ __sdhci_msm_set_clock(host, clock);
+ }
--- /dev/null
+From 970e1e41805f0bd49dc234330a9390f4708d097d Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Wed, 22 Oct 2025 19:53:25 +0800
+Subject: perf: arm_cspmu: fix error handling in arm_cspmu_impl_unregister()
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 970e1e41805f0bd49dc234330a9390f4708d097d upstream.
+
+driver_find_device() calls get_device() to increment the reference
+count once a matching device is found. device_release_driver()
+releases the driver, but it does not decrease the reference count that
+was incremented by driver_find_device(). At the end of the loop, there
+is no put_device() to balance the reference count. To avoid reference
+count leakage, add put_device() to decrease the reference count.
+
+Found by code review.
+
+Cc: stable@vger.kernel.org
+Fixes: bfc653aa89cb ("perf: arm_cspmu: Separate Arm and vendor module")
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/perf/arm_cspmu/arm_cspmu.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/perf/arm_cspmu/arm_cspmu.c
++++ b/drivers/perf/arm_cspmu/arm_cspmu.c
+@@ -1412,8 +1412,10 @@ void arm_cspmu_impl_unregister(const str
+
+ /* Unbind the driver from all matching backend devices. */
+ while ((dev = driver_find_device(&arm_cspmu_driver.driver, NULL,
+- match, arm_cspmu_match_device)))
++ match, arm_cspmu_match_device))) {
+ device_release_driver(dev);
++ put_device(dev);
++ }
+
+ mutex_lock(&arm_cspmu_lock);
+
--- /dev/null
+From c943bfc6afb8d0e781b9b7406f36caa8bbf95cb9 Mon Sep 17 00:00:00 2001
+From: Stefan Haberland <sth@linux.ibm.com>
+Date: Wed, 26 Nov 2025 17:06:31 +0100
+Subject: s390/dasd: Fix gendisk parent after copy pair swap
+
+From: Stefan Haberland <sth@linux.ibm.com>
+
+commit c943bfc6afb8d0e781b9b7406f36caa8bbf95cb9 upstream.
+
+After a copy pair swap the block device's "device" symlink points to
+the secondary CCW device, but the gendisk's parent remained the
+primary, leaving /sys/block/<dasdx> under the wrong parent.
+
+Move the gendisk to the secondary's device with device_move(), keeping
+the sysfs topology consistent after the swap.
+
+Fixes: 413862caad6f ("s390/dasd: add copy pair swap capability")
+Cc: stable@vger.kernel.org #6.1
+Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
+Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/block/dasd_eckd.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/s390/block/dasd_eckd.c
++++ b/drivers/s390/block/dasd_eckd.c
+@@ -6149,6 +6149,7 @@ static int dasd_eckd_copy_pair_swap(stru
+ struct dasd_copy_relation *copy;
+ struct dasd_block *block;
+ struct gendisk *gdp;
++ int rc;
+
+ copy = device->copy;
+ if (!copy)
+@@ -6183,6 +6184,13 @@ static int dasd_eckd_copy_pair_swap(stru
+ /* swap blocklayer device link */
+ gdp = block->gdp;
+ dasd_add_link_to_gendisk(gdp, secondary);
++ rc = device_move(disk_to_dev(gdp), &secondary->cdev->dev, DPM_ORDER_NONE);
++ if (rc) {
++ dev_err(&primary->cdev->dev,
++ "copy_pair_swap: moving blockdevice parent %s->%s failed (%d)\n",
++ dev_name(&primary->cdev->dev),
++ dev_name(&secondary->cdev->dev), rc);
++ }
+
+ /* re-enable device */
+ dasd_device_remove_stop_bits(primary, DASD_STOPPED_PPRC);
block-rnbd-clt-fix-signedness-bug-in-init_dev.patch
vhost-vsock-improve-rcu-read-sections-around-vhost_v.patch
cifs-fix-memory-and-information-leak-in-smb3_reconfi.patch
+keys-trusted-fix-a-memory-leak-in-tpm2_load_cmd.patch
+io_uring-fix-filename-leak-in-__io_openat_prep.patch
+x86-mce-do-not-clear-bank-s-poll-bit-in-mce_poll_banks-on-amd-smca-systems.patch
+mmc-sdhci-msm-avoid-early-clock-doubling-during-hs400-transition.patch
+perf-arm_cspmu-fix-error-handling-in-arm_cspmu_impl_unregister.patch
+lib-crypto-x86-blake2s-fix-32-bit-arg-treated-as-64-bit.patch
+s390-dasd-fix-gendisk-parent-after-copy-pair-swap.patch
+wifi-mt76-fix-dts-power-limits-on-little-endian-systems.patch
+block-rate-limit-capacity-change-info-log.patch
+floppy-fix-for-page_size-4kb.patch
+kallsyms-fix-wrong-big-kernel-symbol-type-read-from-procfs.patch
+fs-ntfs3-fix-mount-failure-for-sparse-runs-in-run_unpack.patch
+ktest.pl-fix-uninitialized-var-in-config-bisect.pl.patch
+tpm-cap-the-number-of-pcr-banks.patch
--- /dev/null
+From faf07e611dfa464b201223a7253e9dc5ee0f3c9e Mon Sep 17 00:00:00 2001
+From: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
+Date: Tue, 30 Sep 2025 15:58:02 +0300
+Subject: tpm: Cap the number of PCR banks
+
+From: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
+
+commit faf07e611dfa464b201223a7253e9dc5ee0f3c9e upstream.
+
+tpm2_get_pcr_allocation() does not cap any upper limit for the number of
+banks. Cap the limit to eight banks so that out of bounds values coming
+from external I/O cause on only limited harm.
+
+Cc: stable@vger.kernel.org # v5.10+
+Fixes: bcfff8384f6c ("tpm: dynamically allocate the allocated_banks array")
+Tested-by: Lai Yi <yi1.lai@linux.intel.com>
+Reviewed-by: Jonathan McDowell <noodles@meta.com>
+Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/tpm/tpm-chip.c | 1 -
+ drivers/char/tpm/tpm1-cmd.c | 5 -----
+ drivers/char/tpm/tpm2-cmd.c | 8 +++-----
+ include/linux/tpm.h | 8 +++++---
+ 4 files changed, 8 insertions(+), 14 deletions(-)
+
+--- a/drivers/char/tpm/tpm-chip.c
++++ b/drivers/char/tpm/tpm-chip.c
+@@ -282,7 +282,6 @@ static void tpm_dev_release(struct devic
+
+ kfree(chip->work_space.context_buf);
+ kfree(chip->work_space.session_buf);
+- kfree(chip->allocated_banks);
+ #ifdef CONFIG_TCG_TPM2_HMAC
+ kfree(chip->auth);
+ #endif
+--- a/drivers/char/tpm/tpm1-cmd.c
++++ b/drivers/char/tpm/tpm1-cmd.c
+@@ -799,11 +799,6 @@ int tpm1_pm_suspend(struct tpm_chip *chi
+ */
+ int tpm1_get_pcr_allocation(struct tpm_chip *chip)
+ {
+- chip->allocated_banks = kcalloc(1, sizeof(*chip->allocated_banks),
+- GFP_KERNEL);
+- if (!chip->allocated_banks)
+- return -ENOMEM;
+-
+ chip->allocated_banks[0].alg_id = TPM_ALG_SHA1;
+ chip->allocated_banks[0].digest_size = hash_digest_size[HASH_ALGO_SHA1];
+ chip->allocated_banks[0].crypto_id = HASH_ALGO_SHA1;
+--- a/drivers/char/tpm/tpm2-cmd.c
++++ b/drivers/char/tpm/tpm2-cmd.c
+@@ -602,11 +602,9 @@ ssize_t tpm2_get_pcr_allocation(struct t
+
+ nr_possible_banks = be32_to_cpup(
+ (__be32 *)&buf.data[TPM_HEADER_SIZE + 5]);
+-
+- chip->allocated_banks = kcalloc(nr_possible_banks,
+- sizeof(*chip->allocated_banks),
+- GFP_KERNEL);
+- if (!chip->allocated_banks) {
++ if (nr_possible_banks > TPM2_MAX_PCR_BANKS) {
++ pr_err("tpm: out of bank capacity: %u > %u\n",
++ nr_possible_banks, TPM2_MAX_PCR_BANKS);
+ rc = -ENOMEM;
+ goto out;
+ }
+--- a/include/linux/tpm.h
++++ b/include/linux/tpm.h
+@@ -26,7 +26,9 @@
+ #include <crypto/aes.h>
+
+ #define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
+-#define TPM_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
++
++#define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
++#define TPM2_MAX_PCR_BANKS 8
+
+ struct tpm_chip;
+ struct trusted_key_payload;
+@@ -68,7 +70,7 @@ enum tpm2_curves {
+
+ struct tpm_digest {
+ u16 alg_id;
+- u8 digest[TPM_MAX_DIGEST_SIZE];
++ u8 digest[TPM2_MAX_DIGEST_SIZE];
+ } __packed;
+
+ struct tpm_bank_info {
+@@ -188,7 +190,7 @@ struct tpm_chip {
+ unsigned int groups_cnt;
+
+ u32 nr_allocated_banks;
+- struct tpm_bank_info *allocated_banks;
++ struct tpm_bank_info allocated_banks[TPM2_MAX_PCR_BANKS];
+ #ifdef CONFIG_ACPI
+ acpi_handle acpi_dev_handle;
+ char ppi_version[TPM_PPI_VERSION_LEN + 1];
--- /dev/null
+From 38b845e1f9e810869b0a0b69f202b877b7b7fb12 Mon Sep 17 00:00:00 2001
+From: "Sven Eckelmann (Plasma Cloud)" <se@simonwunderlich.de>
+Date: Fri, 26 Sep 2025 11:32:54 +0200
+Subject: wifi: mt76: Fix DTS power-limits on little endian systems
+
+From: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de>
+
+commit 38b845e1f9e810869b0a0b69f202b877b7b7fb12 upstream.
+
+The power-limits for ru and mcs and stored in the devicetree as bytewise
+array (often with sizes which are not a multiple of 4). These arrays have a
+prefix which defines for how many modes a line is applied. This prefix is
+also only a byte - but the code still tried to fix the endianness of this
+byte with a be32 operation. As result, loading was mostly failing or was
+sending completely unexpected values to the firmware.
+
+Since the other rates are also stored in the devicetree as bytewise arrays,
+just drop the u32 access + be32_to_cpu conversion and directly access them
+as bytes arrays.
+
+Cc: stable@vger.kernel.org
+Fixes: 22b980badc0f ("mt76: add functions for parsing rate power limits from DT")
+Fixes: a9627d992b5e ("mt76: extend DT rate power limits to support 11ax devices")
+Signed-off-by: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de>
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/eeprom.c | 37 ++++++++++++++++++----------
+ 1 file changed, 24 insertions(+), 13 deletions(-)
+
+--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
++++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
+@@ -253,6 +253,19 @@ mt76_get_of_array(struct device_node *np
+ return prop->value;
+ }
+
++static const s8 *
++mt76_get_of_array_s8(struct device_node *np, char *name, size_t *len, int min)
++{
++ struct property *prop = of_find_property(np, name, NULL);
++
++ if (!prop || !prop->value || prop->length < min)
++ return NULL;
++
++ *len = prop->length;
++
++ return prop->value;
++}
++
+ struct device_node *
+ mt76_find_channel_node(struct device_node *np, struct ieee80211_channel *chan)
+ {
+@@ -294,7 +307,7 @@ mt76_get_txs_delta(struct device_node *n
+ }
+
+ static void
+-mt76_apply_array_limit(s8 *pwr, size_t pwr_len, const __be32 *data,
++mt76_apply_array_limit(s8 *pwr, size_t pwr_len, const s8 *data,
+ s8 target_power, s8 nss_delta, s8 *max_power)
+ {
+ int i;
+@@ -303,15 +316,14 @@ mt76_apply_array_limit(s8 *pwr, size_t p
+ return;
+
+ for (i = 0; i < pwr_len; i++) {
+- pwr[i] = min_t(s8, target_power,
+- be32_to_cpu(data[i]) + nss_delta);
++ pwr[i] = min_t(s8, target_power, data[i] + nss_delta);
+ *max_power = max(*max_power, pwr[i]);
+ }
+ }
+
+ static void
+ mt76_apply_multi_array_limit(s8 *pwr, size_t pwr_len, s8 pwr_num,
+- const __be32 *data, size_t len, s8 target_power,
++ const s8 *data, size_t len, s8 target_power,
+ s8 nss_delta, s8 *max_power)
+ {
+ int i, cur;
+@@ -319,8 +331,7 @@ mt76_apply_multi_array_limit(s8 *pwr, si
+ if (!data)
+ return;
+
+- len /= 4;
+- cur = be32_to_cpu(data[0]);
++ cur = data[0];
+ for (i = 0; i < pwr_num; i++) {
+ if (len < pwr_len + 1)
+ break;
+@@ -335,7 +346,7 @@ mt76_apply_multi_array_limit(s8 *pwr, si
+ if (!len)
+ break;
+
+- cur = be32_to_cpu(data[0]);
++ cur = data[0];
+ }
+ }
+
+@@ -346,7 +357,7 @@ s8 mt76_get_rate_power_limits(struct mt7
+ {
+ struct mt76_dev *dev = phy->dev;
+ struct device_node *np;
+- const __be32 *val;
++ const s8 *val;
+ char name[16];
+ u32 mcs_rates = dev->drv->mcs_rates;
+ u32 ru_rates = ARRAY_SIZE(dest->ru[0]);
+@@ -392,21 +403,21 @@ s8 mt76_get_rate_power_limits(struct mt7
+
+ txs_delta = mt76_get_txs_delta(np, hweight16(phy->chainmask));
+
+- val = mt76_get_of_array(np, "rates-cck", &len, ARRAY_SIZE(dest->cck));
++ val = mt76_get_of_array_s8(np, "rates-cck", &len, ARRAY_SIZE(dest->cck));
+ mt76_apply_array_limit(dest->cck, ARRAY_SIZE(dest->cck), val,
+ target_power, txs_delta, &max_power);
+
+- val = mt76_get_of_array(np, "rates-ofdm",
+- &len, ARRAY_SIZE(dest->ofdm));
++ val = mt76_get_of_array_s8(np, "rates-ofdm",
++ &len, ARRAY_SIZE(dest->ofdm));
+ mt76_apply_array_limit(dest->ofdm, ARRAY_SIZE(dest->ofdm), val,
+ target_power, txs_delta, &max_power);
+
+- val = mt76_get_of_array(np, "rates-mcs", &len, mcs_rates + 1);
++ val = mt76_get_of_array_s8(np, "rates-mcs", &len, mcs_rates + 1);
+ mt76_apply_multi_array_limit(dest->mcs[0], ARRAY_SIZE(dest->mcs[0]),
+ ARRAY_SIZE(dest->mcs), val, len,
+ target_power, txs_delta, &max_power);
+
+- val = mt76_get_of_array(np, "rates-ru", &len, ru_rates + 1);
++ val = mt76_get_of_array_s8(np, "rates-ru", &len, ru_rates + 1);
+ mt76_apply_multi_array_limit(dest->ru[0], ARRAY_SIZE(dest->ru[0]),
+ ARRAY_SIZE(dest->ru), val, len,
+ target_power, txs_delta, &max_power);
--- /dev/null
+From d7ac083f095d894a0b8ac0573516bfd035e6b25a Mon Sep 17 00:00:00 2001
+From: Avadhut Naik <avadhut.naik@amd.com>
+Date: Fri, 21 Nov 2025 19:04:04 +0000
+Subject: x86/mce: Do not clear bank's poll bit in mce_poll_banks on AMD SMCA systems
+
+From: Avadhut Naik <avadhut.naik@amd.com>
+
+commit d7ac083f095d894a0b8ac0573516bfd035e6b25a upstream.
+
+Currently, when a CMCI storm detected on a Machine Check bank, subsides, the
+bank's corresponding bit in the mce_poll_banks per-CPU variable is cleared
+unconditionally by cmci_storm_end().
+
+On AMD SMCA systems, this essentially disables polling on that particular bank
+on that CPU. Consequently, any subsequent correctable errors or storms will not
+be logged.
+
+Since AMD SMCA systems allow banks to be managed by both polling and
+interrupts, the polling banks bitmap for a CPU, i.e., mce_poll_banks, should
+not be modified when a storm subsides.
+
+Fixes: 7eae17c4add5 ("x86/mce: Add per-bank CMCI storm mitigation")
+Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20251121190542.2447913-2-avadhut.naik@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/threshold.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/mce/threshold.c
++++ b/arch/x86/kernel/cpu/mce/threshold.c
+@@ -85,7 +85,8 @@ void cmci_storm_end(unsigned int bank)
+ {
+ struct mca_storm_desc *storm = this_cpu_ptr(&storm_desc);
+
+- __clear_bit(bank, this_cpu_ptr(mce_poll_banks));
++ if (!mce_flags.amd_threshold)
++ __clear_bit(bank, this_cpu_ptr(mce_poll_banks));
+ storm->banks[bank].history = 0;
+ storm->banks[bank].in_storm_mode = false;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
