From 90f3bef4f151a21def51b735af330bf42cf74cc4 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 11 Apr 2022 09:40:04 +0200 Subject: [PATCH] 4.14-stable patches added patches: mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.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 --- ...ol_new-leak-in-shared_policy_replace.patch | 51 +++++++++++++++++++ ...range_start-end-on-mremap-old_size-0.patch | 45 ++++++++++++++++ ...-fix-annoying-1.8v-regulator-warning.patch | 49 ++++++++++++++++++ queue-4.14/series | 3 ++ 4 files changed, 148 insertions(+) create mode 100644 queue-4.14/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch create mode 100644 queue-4.14/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch create mode 100644 queue-4.14/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch diff --git a/queue-4.14/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch b/queue-4.14/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch new file mode 100644 index 00000000000..ec648bf8364 --- /dev/null +++ b/queue-4.14/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 +@@ -2479,6 +2479,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-4.14/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch b/queue-4.14/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch new file mode 100644 index 00000000000..0000fdad5b7 --- /dev/null +++ b/queue-4.14/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 +@@ -203,6 +203,9 @@ unsigned long move_page_tables(struct vm + unsigned long mmun_start; /* For mmu_notifiers */ + unsigned long mmun_end; /* For mmu_notifiers */ + ++ if (!len) ++ return 0; ++ + old_end = old_addr + len; + flush_cache_range(vma, old_addr, old_end); + diff --git a/queue-4.14/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch b/queue-4.14/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch new file mode 100644 index 00000000000..b7db7071887 --- /dev/null +++ b/queue-4.14/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 +@@ -243,16 +243,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-4.14/series b/queue-4.14/series index 21b9fea3250..516e2c4513c 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -245,3 +245,6 @@ scsi-zorro7xx-fix-a-resource-leak-in-zorro7xx_remove.patch net-stmmac-fix-unset-max_speed-difference-between-dt.patch drm-imx-fix-memory-leak-in-imx_pd_connector_get_mode.patch drbd-fix-five-use-after-free-bugs-in-get_initial_sta.patch +revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.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 -- 2.47.3