From: Greg Kroah-Hartman Date: Mon, 11 Apr 2022 07:40:25 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.9.310~86 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=e727241c3462db50b3cfd49a7fc7ac5e0ea3e0dc;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch --- diff --git a/queue-5.10/lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch b/queue-5.10/lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch new file mode 100644 index 00000000000..bedfb5adda5 --- /dev/null +++ b/queue-5.10/lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch @@ -0,0 +1,57 @@ +From eafc0a02391b7b36617b36c97c4b5d6832cf5e24 Mon Sep 17 00:00:00 2001 +From: Guo Xuenan +Date: Fri, 8 Apr 2022 13:08:58 -0700 +Subject: lz4: fix LZ4_decompress_safe_partial read out of bound + +From: Guo Xuenan + +commit eafc0a02391b7b36617b36c97c4b5d6832cf5e24 upstream. + +When partialDecoding, it is EOF if we've either filled the output buffer +or can't proceed with reading an offset for following match. + +In some extreme corner cases when compressed data is suitably corrupted, +UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial +may lead to read out of bound problem during decoding. lz4 upstream has +fixed it [2] and this issue has been disscussed here [3] before. + +current decompression routine was ported from lz4 v1.8.3, bumping +lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd +better fix it first. + +[1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ +[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# +[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ + +Link: https://lkml.kernel.org/r/20211111105048.2006070-1-guoxuenan@huawei.com +Reported-by: syzbot+63d688f1d899c588fb71@syzkaller.appspotmail.com +Signed-off-by: Guo Xuenan +Reviewed-by: Nick Terrell +Acked-by: Gao Xiang +Cc: Yann Collet +Cc: Chengyang Fan +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + lib/lz4/lz4_decompress.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/lib/lz4/lz4_decompress.c ++++ b/lib/lz4/lz4_decompress.c +@@ -271,8 +271,12 @@ static FORCE_INLINE int LZ4_decompress_g + ip += length; + op += length; + +- /* Necessarily EOF, due to parsing restrictions */ +- if (!partialDecoding || (cpy == oend)) ++ /* Necessarily EOF when !partialDecoding. ++ * When partialDecoding, it is EOF if we've either ++ * filled the output buffer or ++ * can't proceed with reading an offset for following match. ++ */ ++ if (!partialDecoding || (cpy == oend) || (ip >= (iend - 2))) + break; + } else { + /* may overwrite up to WILDCOPYLENGTH beyond cpy */ diff --git a/queue-5.10/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch b/queue-5.10/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch new file mode 100644 index 00000000000..733ec32d19d --- /dev/null +++ b/queue-5.10/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch @@ -0,0 +1,51 @@ +From 4ad099559b00ac01c3726e5c95dc3108ef47d03e Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Fri, 8 Apr 2022 13:09:07 -0700 +Subject: mm/mempolicy: fix mpol_new leak in shared_policy_replace + +From: Miaohe Lin + +commit 4ad099559b00ac01c3726e5c95dc3108ef47d03e upstream. + +If mpol_new is allocated but not used in restart loop, mpol_new will be +freed via mpol_put before returning to the caller. But refcnt is not +initialized yet, so mpol_put could not do the right things and might +leak the unused mpol_new. This would happen if mempolicy was updated on +the shared shmem file while the sp->lock has been dropped during the +memory allocation. + +This issue could be triggered easily with the below code snippet if +there are many processes doing the below work at the same time: + + shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); + shm = shmat(shmid, 0, 0); + loop many times { + mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); + mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, + maxnode, 0); + } + +Link: https://lkml.kernel.org/r/20220329111416.27954-1-linmiaohe@huawei.com +Fixes: 42288fe366c4 ("mm: mempolicy: Convert shared_policy mutex to spinlock") +Signed-off-by: Miaohe Lin +Acked-by: Michal Hocko +Cc: KOSAKI Motohiro +Cc: Mel Gorman +Cc: [3.8] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mempolicy.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/mempolicy.c ++++ b/mm/mempolicy.c +@@ -2636,6 +2636,7 @@ alloc_new: + mpol_new = kmem_cache_alloc(policy_cache, GFP_KERNEL); + if (!mpol_new) + goto err_out; ++ atomic_set(&mpol_new->refcnt, 1); + goto restart; + } + diff --git a/queue-5.10/mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch b/queue-5.10/mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch new file mode 100644 index 00000000000..840ce644490 --- /dev/null +++ b/queue-5.10/mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch @@ -0,0 +1,46 @@ +From 0d319dd5a27183b75d984e3dc495248e59f99334 Mon Sep 17 00:00:00 2001 +From: Yann Gautier +Date: Thu, 17 Mar 2022 12:19:43 +0100 +Subject: mmc: mmci: stm32: correctly check all elements of sg list + +From: Yann Gautier + +commit 0d319dd5a27183b75d984e3dc495248e59f99334 upstream. + +Use sg and not data->sg when checking sg list elements. Else only the +first element alignment is checked. +The last element should be checked the same way, for_each_sg already set +sg to sg_next(sg). + +Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant") +Cc: stable@vger.kernel.org +Signed-off-by: Yann Gautier +Link: https://lore.kernel.org/r/20220317111944.116148-2-yann.gautier@foss.st.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/mmci_stm32_sdmmc.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/mmc/host/mmci_stm32_sdmmc.c ++++ b/drivers/mmc/host/mmci_stm32_sdmmc.c +@@ -62,8 +62,8 @@ static int sdmmc_idma_validate_data(stru + * excepted the last element which has no constraint on idmasize + */ + for_each_sg(data->sg, sg, data->sg_len - 1, i) { +- if (!IS_ALIGNED(data->sg->offset, sizeof(u32)) || +- !IS_ALIGNED(data->sg->length, SDMMC_IDMA_BURST)) { ++ if (!IS_ALIGNED(sg->offset, sizeof(u32)) || ++ !IS_ALIGNED(sg->length, SDMMC_IDMA_BURST)) { + dev_err(mmc_dev(host->mmc), + "unaligned scatterlist: ofst:%x length:%d\n", + data->sg->offset, data->sg->length); +@@ -71,7 +71,7 @@ static int sdmmc_idma_validate_data(stru + } + } + +- if (!IS_ALIGNED(data->sg->offset, sizeof(u32))) { ++ if (!IS_ALIGNED(sg->offset, sizeof(u32))) { + dev_err(mmc_dev(host->mmc), + "unaligned last scatterlist: ofst:%x length:%d\n", + data->sg->offset, data->sg->length); diff --git a/queue-5.10/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch b/queue-5.10/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch new file mode 100644 index 00000000000..f7fc346e195 --- /dev/null +++ b/queue-5.10/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch @@ -0,0 +1,41 @@ +From 03e59b1e2f56245163b14c69e0a830c24b1a3a47 Mon Sep 17 00:00:00 2001 +From: Wolfram Sang +Date: Mon, 4 Apr 2022 13:49:02 +0200 +Subject: mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete + +From: Wolfram Sang + +commit 03e59b1e2f56245163b14c69e0a830c24b1a3a47 upstream. + +When HS400 tuning is complete and HS400 is going to be activated, we +have to keep the current number of TAPs and should not overwrite them +with a hardcoded value. This was probably a copy&paste mistake when +upporting HS400 support from the BSP. + +Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") +Reported-by: Yoshihiro Shimoda +Signed-off-by: Wolfram Sang +Reviewed-by: Yoshihiro Shimoda +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220404114902.12175-1-wsa+renesas@sang-engineering.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/renesas_sdhi_core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/host/renesas_sdhi_core.c ++++ b/drivers/mmc/host/renesas_sdhi_core.c +@@ -390,10 +390,10 @@ static void renesas_sdhi_hs400_complete( + SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) | + sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2)); + +- /* Set the sampling clock selection range of HS400 mode */ + sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL, + SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN | +- 0x4 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT); ++ sd_scc_read32(host, priv, ++ SH_MOBILE_SDHI_SCC_DTCNTL)); + + /* Avoid bad TAP */ + if (bad_taps & BIT(priv->tap_set)) { diff --git a/queue-5.10/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch b/queue-5.10/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch new file mode 100644 index 00000000000..d8b4ca927d4 --- /dev/null +++ b/queue-5.10/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch @@ -0,0 +1,45 @@ +From 01e67e04c28170c47700c2c226d732bbfedb1ad0 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Fri, 8 Apr 2022 13:09:04 -0700 +Subject: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) + +From: Paolo Bonzini + +commit 01e67e04c28170c47700c2c226d732bbfedb1ad0 upstream. + +If an mremap() syscall with old_size=0 ends up in move_page_tables(), it +will call invalidate_range_start()/invalidate_range_end() unnecessarily, +i.e. with an empty range. + +This causes a WARN in KVM's mmu_notifier. In the past, empty ranges +have been diagnosed to be off-by-one bugs, hence the WARNing. Given the +low (so far) number of unique reports, the benefits of detecting more +buggy callers seem to outweigh the cost of having to fix cases such as +this one, where userspace is doing something silly. In this particular +case, an early return from move_page_tables() is enough to fix the +issue. + +Link: https://lkml.kernel.org/r/20220329173155.172439-1-pbonzini@redhat.com +Reported-by: syzbot+6bde52d89cfdf9f61425@syzkaller.appspotmail.com +Signed-off-by: Paolo Bonzini +Cc: Sean Christopherson +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mremap.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/mm/mremap.c ++++ b/mm/mremap.c +@@ -260,6 +260,9 @@ unsigned long move_page_tables(struct vm + struct mmu_notifier_range range; + pmd_t *old_pmd, *new_pmd; + ++ if (!len) ++ return 0; ++ + old_end = old_addr + len; + flush_cache_range(vma, old_addr, old_end); + diff --git a/queue-5.10/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch b/queue-5.10/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch new file mode 100644 index 00000000000..0ff709f083c --- /dev/null +++ b/queue-5.10/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch @@ -0,0 +1,49 @@ +From 7e2646ed47542123168d43916b84b954532e5386 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Fri, 18 Mar 2022 15:14:41 +0100 +Subject: Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit 7e2646ed47542123168d43916b84b954532e5386 upstream. + +This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f. + +Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") +contains proper fix for the issue described in commit bb32e1987bc5 ("mmc: +sdhci-xenon: fix annoying 1.8V regulator warning"). + +Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable") +Cc: stable@vger.kernel.org # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") +Signed-off-by: Pali Rohár +Reviewed-by: Marek Behún +Reviewed-by: Marcin Wojtas +Link: https://lore.kernel.org/r/20220318141441.32329-1-pali@kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sdhci-xenon.c | 10 ---------- + 1 file changed, 10 deletions(-) + +--- a/drivers/mmc/host/sdhci-xenon.c ++++ b/drivers/mmc/host/sdhci-xenon.c +@@ -240,16 +240,6 @@ static void xenon_voltage_switch(struct + { + /* Wait for 5ms after set 1.8V signal enable bit */ + usleep_range(5000, 5500); +- +- /* +- * For some reason the controller's Host Control2 register reports +- * the bit representing 1.8V signaling as 0 when read after it was +- * written as 1. Subsequent read reports 1. +- * +- * Since this may cause some issues, do an empty read of the Host +- * Control2 register here to circumvent this. +- */ +- sdhci_readw(host, SDHCI_HOST_CONTROL2); + } + + static const struct sdhci_ops sdhci_xenon_ops = { diff --git a/queue-5.10/series b/queue-5.10/series index 6184cc02f4c..97bf09a8c71 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -132,3 +132,9 @@ perf-arm-spe-fix-perf-report-mem-mode.patch perf-tools-fix-perf-s-libperf_print-callback.patch perf-session-remap-buf-if-there-is-no-space-for-even.patch arm64-add-part-number-for-arm-cortex-a78ae.patch +revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch +mmc-mmci-stm32-correctly-check-all-elements-of-sg-list.patch +mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch +lz4-fix-lz4_decompress_safe_partial-read-out-of-bound.patch +mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch +mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch