From: Greg Kroah-Hartman Date: Mon, 29 Apr 2024 11:15:43 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v4.19.313~61 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=97373ae32d46a563276632f7eddd8e31ca03e966;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch --- diff --git a/queue-6.6/fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch b/queue-6.6/fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch new file mode 100644 index 00000000000..f58b8f62b92 --- /dev/null +++ b/queue-6.6/fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch @@ -0,0 +1,97 @@ +From 35e351780fa9d8240dd6f7e4f245f9ea37e96c19 Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Wed, 10 Apr 2024 17:14:41 +0800 +Subject: fork: defer linking file vma until vma is fully initialized + +From: Miaohe Lin + +commit 35e351780fa9d8240dd6f7e4f245f9ea37e96c19 upstream. + +Thorvald reported a WARNING [1]. And the root cause is below race: + + CPU 1 CPU 2 + fork hugetlbfs_fallocate + dup_mmap hugetlbfs_punch_hole + i_mmap_lock_write(mapping); + vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. + i_mmap_unlock_write(mapping); + hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! + i_mmap_lock_write(mapping); + hugetlb_vmdelete_list + vma_interval_tree_foreach + hugetlb_vma_trylock_write -- Vma_lock is cleared. + tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! + hugetlb_vma_unlock_write -- Vma_lock is assigned!!! + i_mmap_unlock_write(mapping); + +hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside +i_mmap_rwsem lock while vma lock can be used in the same time. Fix this +by deferring linking file vma until vma is fully initialized. Those vmas +should be initialized first before they can be used. + +Link: https://lkml.kernel.org/r/20240410091441.3539905-1-linmiaohe@huawei.com +Fixes: 8d9bfb260814 ("hugetlb: add vma based lock for pmd sharing") +Signed-off-by: Miaohe Lin +Reported-by: Thorvald Natvig +Closes: https://lore.kernel.org/linux-mm/20240129161735.6gmjsswx62o4pbja@revolver/T/ [1] +Reviewed-by: Jane Chu +Cc: Christian Brauner +Cc: Heiko Carstens +Cc: Kent Overstreet +Cc: Liam R. Howlett +Cc: Mateusz Guzik +Cc: Matthew Wilcox (Oracle) +Cc: Miaohe Lin +Cc: Muchun Song +Cc: Oleg Nesterov +Cc: Peng Zhang +Cc: Tycho Andersen +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Miaohe Lin +Signed-off-by: Greg Kroah-Hartman +--- + kernel/fork.c | 18 +++++++++--------- + 1 file changed, 9 insertions(+), 9 deletions(-) + +--- a/kernel/fork.c ++++ b/kernel/fork.c +@@ -727,6 +727,15 @@ static __latent_entropy int dup_mmap(str + } else if (anon_vma_fork(tmp, mpnt)) + goto fail_nomem_anon_vma_fork; + vm_flags_clear(tmp, VM_LOCKED_MASK); ++ /* ++ * Copy/update hugetlb private vma information. ++ */ ++ if (is_vm_hugetlb_page(tmp)) ++ hugetlb_dup_vma_private(tmp); ++ ++ if (tmp->vm_ops && tmp->vm_ops->open) ++ tmp->vm_ops->open(tmp); ++ + file = tmp->vm_file; + if (file) { + struct address_space *mapping = file->f_mapping; +@@ -743,12 +752,6 @@ static __latent_entropy int dup_mmap(str + i_mmap_unlock_write(mapping); + } + +- /* +- * Copy/update hugetlb private vma information. +- */ +- if (is_vm_hugetlb_page(tmp)) +- hugetlb_dup_vma_private(tmp); +- + /* Link the vma into the MT */ + if (vma_iter_bulk_store(&vmi, tmp)) + goto fail_nomem_vmi_store; +@@ -757,9 +760,6 @@ static __latent_entropy int dup_mmap(str + if (!(tmp->vm_flags & VM_WIPEONFORK)) + retval = copy_page_range(tmp, mpnt); + +- if (tmp->vm_ops && tmp->vm_ops->open) +- tmp->vm_ops->open(tmp); +- + if (retval) + goto loop_out; + } diff --git a/queue-6.6/series b/queue-6.6/series index a56a14339f9..a7e041ef675 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -107,3 +107,5 @@ squashfs-check-the-inode-number-is-not-the-invalid-v.patch selftests-seccomp-user_notification_addfd-check-nextfd-is-available.patch selftests-seccomp-change-the-syscall-used-in-kill_thread-test.patch selftests-seccomp-handle-einval-on-unshare-clone_newpid.patch +fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch +x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch diff --git a/queue-6.6/x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch b/queue-6.6/x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch new file mode 100644 index 00000000000..88b15ae7999 --- /dev/null +++ b/queue-6.6/x86-cpu-fix-check-for-rdpkru-in-__show_regs.patch @@ -0,0 +1,42 @@ +From b53c6bd5d271d023857174b8fd3e32f98ae51372 Mon Sep 17 00:00:00 2001 +From: David Kaplan +Date: Sun, 21 Apr 2024 21:17:28 +0200 +Subject: x86/cpu: Fix check for RDPKRU in __show_regs() + +From: David Kaplan + +commit b53c6bd5d271d023857174b8fd3e32f98ae51372 upstream. + +cpu_feature_enabled(X86_FEATURE_OSPKE) does not necessarily reflect +whether CR4.PKE is set on the CPU. In particular, they may differ on +non-BSP CPUs before setup_pku() is executed. In this scenario, RDPKRU +will #UD causing the system to hang. + +Fix by checking CR4 for PKE enablement which is always correct for the +current CPU. + +The scenario happens by inserting a WARN* before setup_pku() in +identiy_cpu() or some other diagnostic which would lead to calling +__show_regs(). + + [ bp: Massage commit message. ] + +Signed-off-by: David Kaplan +Signed-off-by: Borislav Petkov (AMD) +Link: https://lore.kernel.org/r/20240421191728.32239-1-bp@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/process_64.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/process_64.c ++++ b/arch/x86/kernel/process_64.c +@@ -138,7 +138,7 @@ void __show_regs(struct pt_regs *regs, e + log_lvl, d3, d6, d7); + } + +- if (cpu_feature_enabled(X86_FEATURE_OSPKE)) ++ if (cr4 & X86_CR4_PKE) + printk("%sPKRU: %08x\n", log_lvl, read_pkru()); + } +