From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794047166; b=CF3JNP8rhvqcZ7EbbemvtD4uE1tFcyCQgPwrfJJJCwMdCAbTJS6Wj0rangFvr1in9Tzz pdoWBlRkZ3aGTyk08UcS+0IuZ48PJqBuMKKN8e4OE2+xU6RYTZ9nR+ybfD3A+AuqumwW1 zMuQFtoTbj4qGcWSBrKn4NAspAjNpvT/lzqmkDRBFe0KMnqPWxhvlu6jfmm2dYF1hd2xD XxoI6JoMMw+SGQUum4B3CJaSBIJHBM+kXuTvT1p7HQ7P6GAl3K7oeTv6fZU8FDeOYLkJo eu7ytfKknBTLS0cylarSAu23eS+GBxATFzsZVGKZWg2WzxYEwtB+3OhftiRAjJjfI4g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794047166; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=4h8a8fTiSKFipZw9iMy+Q9GOpUJz3gQqI1QrcwbN1ec=; b=aua+4caz4MM0EIDncg1Ege24c0TqquuA9wbRIc0RrQm6Q10VY2x+p4uB/2EahWQ4WwBw wOm1THLo+yXfz1eL2q0MYW/91xrTCPpjQsbN/u7dFHekDknMdIf3UHuxEB3EYj3W+eu5w QUaF7XJ0Jape9krBg/bKR+tJj6BfdfBHHJCqhz3xPo/1zWJ2QEJXbfAUQnO4SCIMS8iHH /FjgtWPCwBzU6dVN9yVsG63SDz199GYg49+Cb/Mkailj6E0TOjgOJswOVJdmK/ZLF79Sk vNe0QKint8xdct0Pg57avDEPJtDm1jfqGViThwRkTTXJcqchX+AvEn9LNjNnzK64glw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=FA3J6Vsn; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C325606A32C for ; Sat, 7 Nov 2026 10:26:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=FA3J6Vsn Received: by smtp.kernel.org (Postfix) with ESMTPSA id 612171F0089F; Sat, 7 Nov 2026 10:26:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794047166; bh=4h8a8fTiSKFipZw9iMy+Q9GOpUJz3gQqI1QrcwbN1ec=; h=From:To:Cc:Subject:Date; b=FA3J6VsnsA005o2NKzJFhuvZwkkfW947lh1dKjuPD0RL6zzdanJchy3AW5CtFpjbD Y4SCYK6WsiPoyLNCCp3GyUdAtiwTxoX49K7wU/Ab7DOYZggNqbTXY56Byl1baHwrgx ePxieVULeJLyuVhwOszU2qdkxCHKFWVTqcgyKQEHvz9odWwjMoGCa/9c0na0uloecn 7Xw3deJqdA7P5YY8FO3WI117/tSEcYVdNbtkIpCWwau3oknKIzHwkWp9Wx4WVR3NmF NenghpPb1CNemKSRcOiFjrRn0i0sd0LLe96BNPzmdjTQSPPJjY6cWX8fvzSoilqhZ6 OBztcl3h9IP3A== From: Sasha Levin To: josef@toxicpanda.com, david@kernel.org, akpm@linux-foundation.org, mason@kernel.org, ljs@kernel.org, muchun.song@linux.dev, lance.yang@linux.dev, liam@infradead.org, vbabka@kernel.org, jannh@google.com, pfalcato@suse.de, osalvador@suse.de, linmiaohe@huawei.com, nao.horiguchi@gmail.com, agl@us.ibm.com, mgorman@techsingularity.net, riel@surriel.com, peterx@redhat.com, kas@kernel.org, rppt@kernel.org Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] mm/hugetlb: unmap the page where the other VMA maps it" failed to apply to 6.12-stable tree Date: Sat, 7 Nov 2026 05:26:03 -0500 Message-ID: <20261107052603-failed-6.12-ae99c503eb36@kernel.org> X-Mailer: git-send-email 2.53.0 X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x ae99c503eb362b42cd5d24d80bc6cba669acc4c2 # git commit -s git send-email --to '' --in-reply-to '20261107052603-failed-6.12-ae99c503eb36@kernel.org' --subject-prefix 'PATCH 6.12.y' 'HEAD^..' Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From ae99c503eb362b42cd5d24d80bc6cba669acc4c2 Mon Sep 17 00:00:00 2001 From: Josef Bacik Date: Thu, 15 Oct 2026 18:07:10 +0200 Subject: [PATCH] mm/hugetlb: unmap the page where the other VMA maps it If the owner of a MAP_PRIVATE hugetlb mapping fails to allocate a page for CoW, unmap_ref_private() unmaps the old page from all other private VMAs that have no reservation of their own. It finds them by the offset in the file, but then zaps each of them at the address of the faulting VMA. Nothing says that another VMA maps the offset at that address: a child can have moved its copy of the VMA with mremap(), and a second mapping of the file is wherever mmap() has put it. So __unmap_hugepage_range() walks the page tables of the other mm at an address outside of iter_vma, where i_mmap_rwsem of this file protects nothing and where anything can be mapped, and the page stays mapped where it really is. All of the following was seen on v7.3-rc6+ (g6c377d19d4a5) in KVM guests, as a user without any privilege. It takes a pool of 2 MiB pages with no free page that is not reserved, so that the allocation fails: the user can take or reserve what is free itself. - The child moves its VMA away. The page is never unmapped, the mapcount stays 2, and the owner goes round retry_avoidcopy in hugetlb_wp() until the child is gone or a page becomes free. SIGKILL to the owner does not end it. 5 of 5 runs. - The owner's mm has a second private mapping of the offset, made with MAP_NORESERVE. The owner zaps its own entry and reads zeroes where its data was. 5 of 5 runs. - The child moves its VMA away and maps a 1 GiB hugetlb page at the old address, so this one takes a pool with a 1 GiB page as well. huge_pte_offset() for the 2 MiB size steps through the PUD leaf, so the "PMD table" is the 1 GiB page itself and its "page table lock" is folio->private of that page, which holds 2. Kernels with lock debugging oops in __unmap_hugepage_range(), 7 of 7 runs. Others spin on that word for ever with preemption disabled, 5 of 5 runs: watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [u_det3:130] RIP: 0010:queued_spin_lock_slowpath+0x8a/0x290 RAX: 0000000000000002 RBX: ffffea0001000028 Call Trace: __unmap_hugepage_range+0x154/0x6d0 unmap_hugepage_range+0xc1/0x140 hugetlb_wp+0x55c/0x700 hugetlb_fault+0x5f3/0x8f0 RCU stalls follow, and killing all tasks of the user changes nothing. Four such owners, whose children share a single 1 GiB page, took down the whole guest with its four CPUs, 2 of 2 runs: one reported soft lockups on all four, the other gave no sign of life any more. i_mmap_rwsem stays write locked. With a MAP_PRIVATE mapping of a hugetlbfs file that belongs to another user, and that the attacker can only read, the next mmap() of that file by its owner sleeps uninterruptibly in __mmap_region(), 4 of 4 runs. Compute the address from the offset for each VMA. The tree walk returns only VMAs that cover pgoff, and vm_start, vm_end and vm_pgoff of a hugetlb VMA are aligned to the huge page size, as pgoff is, so the whole range lies inside iter_vma. Its page tables can not go away there, since the VMA is unlinked from the file under i_mmap_rwsem first. With the right address the page is unmapped from all VMAs but the owner's, so the retry in hugetlb_wp() finds a mapcount of 1 and reuses the page. A child that has moved its copy of the VMA now loses the page, and gets SIGBUS when it faults on a missing page of that VMA. That is what the comment above the function has always promised to those who do not own the reservation, and what already happens to a child that has left the VMA in place. The address has been wrong from the start, and the second case needs only mmap() and fork(). mremap() of hugetlb VMAs, which the other cases use, came with commit 550a7d60bd5e ("mm, hugepages: add mremap() support for hugepage backed vma") in v5.16. Original fix generated by an LLM and sent in private by Josef. [david@kernel.org: switch to vma_filebacked_address, add VM_WARN_ON_ONCE, refine comments] Link: https://lore.kernel.org/20261015-urgent_fixes-v1-4-42796911043b@kernel.org Fixes: 04f2cbe35699 ("hugetlb: guarantee that COW faults for a process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed") Signed-off-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton Reported-by: Chris Mason Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: Muchun Song Reviewed-by: Lance Yang Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Oscar Salvador Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Adam Litke Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Xu Cc: Kiryl Shutsemau Cc: Mike Rapoport Cc: --- mm/hugetlb.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 5db64fa984041..4fca859bbd7ea 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5482,6 +5482,8 @@ static void unmap_ref_private(struct mm_struct *mm, struct vm_area_struct *vma, struct address_space *mapping; pgoff_t pgoff; + VM_WARN_ON_ONCE(!folio_test_anon(folio)); + /* * vm_pgoff is in PAGE_SIZE units, hence the different calculation * from page cache lookup which is in HPAGE_SIZE units. @@ -5516,10 +5518,17 @@ static void unmap_ref_private(struct mm_struct *mm, struct vm_area_struct *vma, * could insert a zeroed page instead of the data existing * from the time of fork. This would look like data corruption */ - if (!is_vma_resv_set(iter_vma, HPAGE_RESV_OWNER)) - unmap_hugepage_range(iter_vma, address, - address + huge_page_size(h), - folio, 0); + if (is_vma_resv_set(iter_vma, HPAGE_RESV_OWNER)) + continue; + + /* + * The address in other VMAs can differ. Even though our old + * folio is anon, we always operate on the underlying hugetlb + * file. + */ + address = vma_filebacked_address(iter_vma, pgoff, 1); + unmap_hugepage_range(iter_vma, address, + address + huge_page_size(h), folio, 0); } i_mmap_unlock_write(mapping); } -- 2.53.0