From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 946F8549397; Thu, 15 Oct 2026 16:07:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080461; cv=none; b=X8vruSDeAefkdHLkhPSAF6i/YDtivDrp0DPA8QKLdeQiUZC1BHmP3jFak9eSk5s8fy8fpKs0g8w7U2OA6Op4eaqG3yIVIBlaCsw3uhbRRPt7fBNadAyo04Hm34s0Bc4saMGy63QikOV6lcM2o6tIbq2SHNPgAgYg8onzuRFAVDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080461; c=relaxed/simple; bh=ulrZ2V7SJXfVeJxQpvnSpDWRVwaaNecXzCNDtz03vwE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=TPksk7GdqiFigk5e3IQQPZr/9I+cEUm8zb+bpceh9uj5p3BRh0nbh6runBkaGlOXkvV278KQ2HICpcSb8lc9LOvJKrWNQ+1B/qAioDEE4xIZYwht0VxQ+D6pmde5n1m0sLhsj+iWQgBcMUOYl0Bdh6outba9Fam8r59XGnbP+5g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oClVWSoc; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oClVWSoc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B38E1F000C5; Thu, 15 Oct 2026 16:07:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080448; bh=CciFSgIFbCKdkyGPR3RAGdYw4f/ibGwxPnazJEcANEE=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=oClVWSocfqvduPR2ALfzIteEFks2esswxs0F5Y2oZ/OA+HLCsAV/fLlib5j95qPEq +3kZatFC0ANxS/DB0lRArKWAxUA+V/mKeyDOldSMMcAwzYJrl7fu+w2qeL+9QEAvW9 wuui8iSP/G/wc3mZPtq8nFawHp2pPEOzw51/wgIO95YwNYlx/8OW3tO/V1wUyYm4tT upGx+ji2prBVevtIwEgY38MI2o90fU5H4R7Z4KqZgUtrXG6Ju8afkoBoaF1ddxngwY Po9NzE5sqCS6nyjwxUxNtqLm3ObuglI8ZrMX9ToVMbhjAcpB0CN5NbdfdbsNMob9kS 2W5jC2QjzjP8Q== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:07 +0200 Subject: [PATCH 01/10] mm/vma: don't leak the commit charge on mmap failure Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-1-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3090; i=david@kernel.org; h=from:subject:message-id; bh=PrdvM6UwTy8T7DRmlAnUC/i1CY7asN3v2e9tohKJ6aM=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DL+dvLjnYVC5XPumHP1rnrR8tnh5Ik9fX+myYXLh yzxUueQ7yhlYRDjYJAVU2QJCr5v8PLlutpqNz5mmDmsTCBDGLg4BWAimlEM/9OLcg34K3TmMjy/ kizyN7FEZ63Q0ohiPqWsv16H3Lcl3GJkeHSnM3SLOv/CjvtnxW7K8s5Zt2/jtcrvfBc3rCpTutd iwAkA X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik When an accountable mapping replaces existing mappings (MAP_FIXED), __mmap_setup() only charges the difference between the size of the new mapping and the VM_ACCOUNT pages it replaces. It then zeroes vms->nr_accounted so that unmapping the old VMAs does not return their charge, which now backs the new mapping. If the operation fails after that point, the error path returns map->charged, i.e. only the difference. By then vms_clean_up_area() has zapped the page tables and closed the old VMAs, so vms_abort_munmap_vmas() cannot reattach them. It leaves a gap and finishes the unmap with vms_complete_munmap_vmas(), which uncharges vms->nr_accounted =3D=3D 0 pages. The old VMAs are gone, the new one was never created, and the charge of the old ones is never returned, not even when the process exits. No privilege is needed to hit this, only a file whose mmap hook fails, for example a socket (sock_no_mmap() returns -ENODEV): p =3D mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); mmap(p, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED, socket_fd, 0); Every iteration adds len to Committed_AS for good. With vm.overcommit_memory=3D2 this lets any user make all further accountable allocations in the system fail with -ENOMEM. Once the new mapping has taken over the charge of the mappings it replaces, it owns the charge for all of its pages. Record that in map->charged, so that the error path returns all of it. A failure in __mmap_setup() itself is not affected: it happens before the charge is taken over and the old VMAs are reattached with their charge intact. Original fix generated by an LLM and sent in private by Josef. Fixes: 4f87153e82c4 ("mm: change failure of MAP_FIXED to restoring the gap = on failure") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Reviewed-by: Lorenzo Stoakes (ARM) [ david: call variable "uncharged" and make it const, adjust/simplify comme= nts ] Signed-off-by: David Hildenbrand (Arm) Reviewed-by: Jose A. Perez de Azpillaga Reviewed-by: Lance Yang Reviewed-by: Pedro Falcato --- mm/vma.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/mm/vma.c b/mm/vma.c index 6c35f0d775ab6..81e2c93a1cc52 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2577,14 +2577,17 @@ static int __mmap_setup(struct mmap_state *map, str= uct vm_area_desc *desc, =20 /* Private writable mapping: check memory availability. */ if (accountable_mapping(map)) { - map->charged =3D map->pglen; - map->charged -=3D vms->nr_accounted; - if (map->charged) { - error =3D security_vm_enough_memory_mm(map->mm, map->charged); + const unsigned long uncharged =3D map->pglen - vms->nr_accounted; + + /* Charge only what's not already charged by mappings we replace. */ + if (uncharged) { + error =3D security_vm_enough_memory_mm(map->mm, uncharged); if (error) return error; } =20 + /* Our new mapping owns the entire charge now. */ + map->charged =3D map->pglen; vms->nr_accounted =3D 0; vma_flags_set(&map->vma_flags, VMA_ACCOUNT_BIT); } --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 477E73E1CE4; Thu, 15 Oct 2026 16:07:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080467; cv=none; b=YTY6oRRNwo6hgQTcoDzpaCuxVQdanXa7PFnUQKJJQLakwm7NFyotBPtTvkLluTJ7nClWnoygO+0dWEK5cX3ftCOf7180VKkbOkdR7OdTMZ2RB3y96DQJqmloW1dPjeEUSZwFPiU9urOYPe1XyogkDLSqdTLjoNqqDwybiwKj2n0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080467; c=relaxed/simple; bh=9iPymqgWixsb8XHF4y8ArQPMoEGci1kIerOEwFe2tIQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=pvPiRwh8lcraFBl3nc0Ssd7hFevbO++VmAXJvkFQpHfAtcWpbJLeQLQZdysUfhNHD8sQNJcl8Kti5mSKCkN0FjhAPYO/9hi5RkbtNrtZgfXOfMh87Q1aKPTWQLcMz45sw82Tjukk5ToTt7uA90pBMcVchCURLxh9GGNeP3djklo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Srjq4clX; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Srjq4clX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 699971F000C9; Thu, 15 Oct 2026 16:07:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080454; bh=36klJXXC0aAnOR97CHQ7Hc6li6xJpMIjRx0K78eNZ4U=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Srjq4clXVSQXEKQQlseICrzLRzIL6wBQhcIt4doE6Kwl5gbMmc0wlsf6RN8bK1LLn zhWDaGukT2jrCeQzR2HzZ3LozLDLPs39jjDarJ15nC6DD23d8gb3jazVZqXv21R+AF v9w8crQBLYPFVy1/JBxiOdNYElWhXNJE193aSkpDaqlg8QTSA7oC1szVNXNkY7uh3R OCdxnZGaJtcVHFF13Mox6RIxXCbJoIghfz3LrFcsyV7Y42FhpXp+/H+zk2ngsQVUzw cIvoFw3KkFURsSvPVUyJUqiQOsYU+sAy29s7hQg92vQR+mSRS+J8ehoikT9/fn5Eup HVFEXI1FOkPpQ== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:08 +0200 Subject: [PATCH 02/10] mm/hugetlb: fix use-after-free of a new anon folio Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-2-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3241; i=david@kernel.org; h=from:subject:message-id; bh=/+TVzqw3aRMIyr8brH6Ah9l55OImF6leRLWzdkIev/I=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DJeq/J/o3CE/kphCbsFRw9VzbnyqWO/yvPul9WtO 1YpnG1M6ihlYRDjYJAVU2QJCr5v8PLlutpqNz5mmDmsTCBDGLg4BWAih+4z/M/M1Fbq81TtXKcW fiPFQoOh8nS3l9TJw1sFVwre2LunYi0jw97l0wt0ndl1HFWPhOy5eKTqrmHievE75rtz30h47L2 kzw0A X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik For a fault in a private mapping with nothing in the page cache, hugetlb_no_page() allocates a folio, locks it and maps it. The folio has one reference, which belongs to the page table entry from then on. After dropping the page table lock the function still sets the migratable flag of the folio and unlocks it. Whoever zaps the entry in between frees the folio. The fault holds the fault mutex and the lock of the vma. MADV_DONTNEED and the first unmap of a hole punch, hugetlb_vmdelete_list(), do not take the fault mutex, and a private vma only has a lock if it owns a reservation map: not with MAP_NORESERVE, and not in the child after fork(). Then the flag is set in, and folio_unlock() is called on, a folio that is free or has a new owner. A surplus page goes back to the page allocator while it is locked: BUG: Bad page state in process init pfn:108e00 flags: 0x200000000000059(locked|uptodate|dirty|head|node=3D0|zone=3D2) page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set A page of the pool can be given to the next user, of any file, who locks it and loses the lock to the late folio_unlock(): kernel BUG at mm/filemap.c:1532! hugetlb_no_page+0x111b/0x23e0 hugetlb_fault+0x3a9/0x14a0 An unprivileged process is enough: threads that write to a MAP_PRIVATE | MAP_NORESERVE hugetlb mapping, threads that call MADV_DONTNEED on it, and one that takes the freed pages for another file. Until commit 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more pmd sharing synchronization") the fault held i_mmap_rwsem for reading, which everybody who zaps takes for writing. The lock that commit bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") gave to private vmas closed the window again, but only for those with a reservation map. Be done with the folio before the page table lock is dropped, as hugetlb_wp() is with its copy. The function already unlocks page cache folios under that lock. Original fix generated by an LLM and sent in private by Josef. Fixes: 3a47c54f09c4 ("hugetlbfs: revert use i_mmap_rwsem for more pmd shari= ng synchronization") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Reviewed-by: Lorenzo Stoakes (ARM) [ david: simplify+move comment ] Signed-off-by: David Hildenbrand (Arm) Acked-by: Muchun Song Reviewed-by: Lance Yang --- mm/hugetlb.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index cea25773a6c95..ce9e87228ec62 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5949,8 +5949,6 @@ static vm_fault_t hugetlb_no_page(struct address_spac= e *mapping, ret =3D hugetlb_wp(vmf); } =20 - spin_unlock(vmf->ptl); - /* * Only set hugetlb_migratable in newly allocated pages. Existing pages * found in the pagecache may not have hugetlb_migratable if they have @@ -5961,6 +5959,12 @@ static vm_fault_t hugetlb_no_page(struct address_spa= ce *mapping, =20 if (folio_locked) folio_unlock(folio); + + /* + * Hold the PTL until we're done with the folio: the page table owns the + * folio reference now. + */ + spin_unlock(vmf->ptl); out: hugetlb_vma_unlock_read(vma); =20 --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFE9E37F74B; Thu, 15 Oct 2026 16:07:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080478; cv=none; b=lFOto30WoilefsJj1uiWkzoidXgoHcXFoZT6PGUfY7/sPVjGnq8/9EHs06sK4jIkeTTav5/WIZ2LoSsv2V3RH41Z+/Vd4/3ODXJVDnxlVsc3HOVUFUQSuGX7B6G2KZX/jwB2s0HlZG4EMlyx+CWzuv3otD3roZR6a76aRbhd9Ic= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080478; c=relaxed/simple; bh=Hw68Xl0G1E+o58UO13jm0l+jupYSoJKy2G+eUgleY7o=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=taK6mmGGDmjZCjHTLsEk2L2pKdi7YQSs3B1BL7ZiIye0RQnTKnyK8gjvOXGIYgo0CZDFuGDJuWX2ukUvhUCfllb/jnCwqxcFMRXDUDZb+/oHRoj0eeYzeVpT6UxPZW0/nMpFSSiXmfgoS1+Ln/LOhjaliBRVzq0ayRhkMfQMrw0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DxcQo8mE; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DxcQo8mE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78B271F000C6; Thu, 15 Oct 2026 16:07:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080461; bh=sxQdEIHHQczO8FrqgYpZ12aLH3TYfe0Zx2M3uMQqQ28=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=DxcQo8mEM+dyXRPVyXdvrAZHITYnPqATklWnP6c59RjxxpgAJdcqsEUGv6vSESwuo eB9X1OXRRgFh33CpYLk7UAJvucKXNiBOU3KoHPXbngY0/RxAYO/wCI8gTS8PWD6/Gl Tm9e0MhdEORTNg42IQUZJ4XIqn4Q3uVIni4Nz9PQ0iXrDo02th0CuF74ZJN9sajcQu V3CK+tIUf/ZwqXsbvaBcjAcI8oupGumCCFqOh7f05ozc+Z6DhDI4/WYfqo2otdZoST xv1BcXxPfntQ0o4QPK+3KYFU/HycxYTVTgwi0RZcp6KxhVQBIO8Ad4GCIrR1ZAifnh lb6XfpoIUL/9A== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:09 +0200 Subject: [PATCH 03/10] mm/hugetlb: fix use-after-free in hugetlb_mfill_atomic_pte() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-3-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1279; i=david@kernel.org; h=from:subject:message-id; bh=Hw68Xl0G1E+o58UO13jm0l+jupYSoJKy2G+eUgleY7o=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DJ+9yLJdP5cZrYNExY1eXS39HxtTig98JP114lf2 /w53H53dZSyMIhxMMiKKbIEBd83ePlyXW21Gx8zzBxWJpAhDFycAjCR4+KMDHMk9zFM7L1bMGV3 0LszuusCAo0a7r1esybkwsMjsu/mfg1mZNjnuv3dokxf6SsGdczXQk0m6JwP2nh3BvtZtmdiMWv /7mMHAA== X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A Let's fix another instance where we use a folio after dropping the PTL, where someone else could e.g., MADV_DONTNEED it once we drop the PTL, making us trigger a use-after-free on the folio. Fixes: cb6acd01e2e4 ("hugetlbfs: fix races and page leaks during migration") Fixes: 1c9e8def43a3 ("userfaultfd: hugetlbfs: add UFFDIO_COPY support for s= hared mappings") Cc: stable@vger.kernel.org Reported-by: Lorenzo Stoakes (ARM) Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: David Hildenbrand (Arm) Acked-by: Muchun Song Reviewed-by: Lance Yang --- mm/hugetlb.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index ce9e87228ec62..86928d76ef12d 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6478,11 +6478,16 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte, /* No need to invalidate - it was non-present before */ update_mmu_cache(dst_vma, dst_addr, dst_pte); =20 - spin_unlock(ptl); if (!is_continue) folio_set_hugetlb_migratable(folio); if (vm_shared || is_continue) folio_unlock(folio); + + /* + * Hold the PTL until we're done with the folio: the page table owns the + * folio reference now. + */ + spin_unlock(ptl); ret =3D 0; out: return ret; --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A9DD53ECFB; Thu, 15 Oct 2026 16:07:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080484; cv=none; b=H7jPtn1RbaxXLbgbYQFBr1gEoI2x4AbY5jrqSmhBAm0jZ/RwpOykPC8ZSEagsPDY00aA36cwt8Pxf3xEbFM/sIZa4mv719ZeUMOD7mUBPzanc6Tdou1hDvdQyOsMYqyzo3vjRYMhmqYAHSIaWr8WzfWGbVMFHbdrc0t9mp6Zbb4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080484; c=relaxed/simple; bh=79SeBC4+XmuWTh61NJmw5Joul9l+RNS4U0+XJ/nMcHE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DL7ySaj+X9TpGeYF/qfBsOM62UIzjNkxvxs1V6+2p21lAKfZ7nWPTSPvywXsSjfZpvVDFbmZBg9CeagfFuPZF6eL34R0DNxstYJQzzRwI5YWDUods17HD7BB4Zh1MRxi/+IzkdIb268skj5njQzH0Yg0B10/fL2zEZmZDszLagc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jszaSfE6; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jszaSfE6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E52151F000C4; Thu, 15 Oct 2026 16:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080467; bh=tTPYoMFTTDcUOlKvocFSekvL0GWvlMdCBCB0mVspP+0=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=jszaSfE6JAU7Q5ThVr7+FWwpwsAeeGIgE3q35qW4nu2TEhjPyeR0W92lkSjFmaJ4c a+jFyOA5hVkGt9ZtlWTG4XYFJYvwrpyUM/Nn7f5ODZFagN+iiWe4lET1tgiBZBlvxh zFARwZn5eIqZPmLbUQsoerde49acYIs5NFaBQzTALwkqIwOuF8wXKJu8G41XZECrpd tyTnxQ6hxd+yap1SbXQYxqesFTEVO2uXiQvDx3SJlzrKT9xlduh4gZcyS0rvwjvIBI dhhPsfYYi2BM02toCPKkpqZkaKJTpfh0LxTilM2q3kQiaru3Lt87uHNuqog3xO2EL4 RJKVKsOpgYpeQ== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:10 +0200 Subject: [PATCH 04/10] mm/hugetlb: unmap the page where the other VMA maps it Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-4-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , Chris Mason , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5795; i=david@kernel.org; h=from:subject:message-id; bh=9QOVq0s2+CpnNKu9MuupRapnouHfqvMDPJ5hA3vXoiA=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DKOuipbV7jY5bdE4XK5Dy1RP+e9+pOccpLZSvGJk kxGi6xQRykLgxgHg6yYIktQ8H2Dly/X1Va78THDzGFlAhnCwMUpABMJ2sHIsLyIP0Bxws2PJuXp P3J/rJQ6PYvl1jKmPXzhb3/zsVmHJzEyvK885ns54BzX4/eFndN5vsj1i6TPv8ohvdLFfPvdhX5 fWAE= X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik 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. Fixes: 04f2cbe35699 ("hugetlb: guarantee that COW faults for a process that= called mmap(MAP_PRIVATE) on hugetlbfs will succeed") Reported-by: Chris Mason Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik [ david: switch to vma_filebacked_address, add VM_WARN_ON_ONCE, refine comm= ents] Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: David Hildenbrand (Arm) Acked-by: Muchun Song Reviewed-by: Lance Yang --- mm/hugetlb.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 86928d76ef12d..86fafd0782987 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5440,6 +5440,8 @@ static void unmap_ref_private(struct mm_struct *mm, s= truct vm_area_struct *vma, struct address_space *mapping; pgoff_t pgoff; =20 + 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. @@ -5474,10 +5476,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 =3D 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); } --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 813C84E36D4; Thu, 15 Oct 2026 16:07:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080490; cv=none; b=BYHcT8JUO8u6I22DJEND9inFP9fzsyod+dZw9Rr6NRdL8iQTG/Vjt1G+r+GZfrz0lsjJEhFJ9nchrVWZf9Xa1kWk+o3OqjQiqDB9IYUNK0ND9HLQQSGzxF9RwAC7zO1IuELjeVCdhhQVnzdAYBlYwiRKJ3NxzrtsUvonAc4XnKU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080490; c=relaxed/simple; bh=pd8piu74erQ8CNcdss8byYglOMa7t3YIsmTvGDewOgk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=cf1HidtxkODEAXKKB9WkiOJ9iJvosfCfBB5EI4Gty3etTe9xP/knblaS0aI5g/SSzVtSlUh1iUGCx2nWMiEOwzY3ScB7rhFjFZSVSgYFA91FxZb51D4z3FHXLJKwjhqJWKCjb9VWSSuMsnLVl/4RxE5UG15SF3YUbytgoHR3tVw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cm+O5AmU; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cm+O5AmU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE8501F000C5; Thu, 15 Oct 2026 16:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080474; bh=hsz2YjjiO+P2ROIu2oZfmqjDi2l2nCSLg69aGUFa1mM=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=cm+O5AmU3+2HUnIWPW+K5lqQV6/iRQx3usBeKCR48KaC+rtCYPWmPlrMDaLMS9tAl 7ZJX3LoxWpIjCYuBMNCIXsEz5Ss0/GdLn/HOWp7F85A6rKb6536sfeNed6QQhz2xgQ PEy2Ox9WpLGbw2yum4YwlFV9aFOEBU9p4PsqYDKTLhFwUpRDKDTJuqc1o47vLvNAKJ 5cePllUTfjFEKrU2gsBLghsjDHYaTxxp9swMtAH4wbrKx7PCGULylcAfdqfCrPOQtU SsrYrT3TB+LkKzbFGcEbbSMDbc/W8of7dHR6vx8Q/bFvvm8wL26H3dH7DlaXiikSla /3ZZT7SduGiPA== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:11 +0200 Subject: [PATCH 05/10] mm/hugetlb: don't clear the resv_map of a VMA whose lock is held Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-5-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , Chris Mason , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3065; i=david@kernel.org; h=from:subject:message-id; bh=QfDlqL7/jpqfjCmtJhEUh7eM+GYniW1rEDmE4ZrUJCw=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DI++Fr1cdRHjsSZOXdrwiccSar79aBi253CmXpd7 h9v25uydZSyMIhxMMiKKbIEBd83ePlyXW21Gx8zzBxWJpAhDFycAjCRummMDOt61ujPPKOgM/Vn d+kX3T+K/clxImwrkvgmWvj1Z2fwlTH8z8o/dbmX5ZFvRfHLrbbxp28/tL5ztjV0/sacyjcv1A2 KeQA= X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik Since commit bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") the lock of a private hugetlb VMA that owns a reservation is the rw_sema of its resv_map. The hugetlb_vma_*lock*() helpers find it through vma->vm_private_data, anew for every lock and every unlock. At the end of mremap() the old VMA has to let go of the resv_map, which now belongs to the new VMA: clear_vma_resv_huge_pages() stores NULL into vm_private_data. mremap() holds mmap_lock for writing and has write locked the VMA, which keeps away everybody who comes through the mm. It does not keep away those who find the VMA through the file. For hole punch and truncation hugetlb_vmdelete_list() does hugetlb_vma_trylock_write(vma); locks resv_map->rw_sema unmap_hugepage_range(vma, ...); vm_private_data =3D NULL hugetlb_vma_unlock_write(vma); no resv_map: does nothing and the rw_sema stays write locked for ever: WARNING: lock held when returning to user space! mremap_punch/116 is leaving the kernel with locks still held! locks held by mremap_punch/116: 1, last CPU#1: #0: (&resv_map->rw_sema){+.+.}-{4:4}, at: hugetlb_vmdelete_list+0x46/0x160 The next fault in the new VMA sleeps in hugetlb_vma_lock_read(), uninterruptibly, and it holds its entry of hugetlb_fault_mutex_table[]. That table is global, so a fault of any other process on a page that hashes to the same entry sleeps uninterruptibly as well. All those who take the lock of a private VMA without taking the mmap/vma lock are affected: rmap walks. So hold i_mmap_rwsem around the clearing of the resv_map. No change of behaviour, other than that mremap() of a hugetlb VMA takes i_mmap_rwsem once more. Original fix generated by an LLM and sent in private by Josef. Fixes: bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs") Reported-by: Chris Mason Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Reviewed-by: Lorenzo Stoakes (ARM) [ david: avoid local variable, move and refine comment, description cleanup= s+simplifications ] Signed-off-by: David Hildenbrand (Arm) Acked-by: Muchun Song Reviewed-by: Lance Yang --- mm/hugetlb.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 86fafd0782987..f8ad2efd472cb 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -7467,6 +7467,15 @@ void hugetlb_unshare_all_pmds(struct vm_area_struct = *vma) */ void fixup_hugetlb_reservations(struct vm_area_struct *vma) { - if (is_vm_hugetlb_page(vma)) - clear_vma_resv_huge_pages(vma); + if (!is_vm_hugetlb_page(vma)) + return; + + /* + * Rmap walks might still find this VMA and take the lock + * inside the reservation map for __vma_private_lock(). Don't clear + * the reservation map while that is possible. + */ + i_mmap_lock_write(vma->vm_file->f_mapping); + clear_vma_resv_huge_pages(vma); + i_mmap_unlock_write(vma->vm_file->f_mapping); } --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 276EE5540B7; Thu, 15 Oct 2026 16:08:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080501; cv=none; b=mYQte+sFjEt92aHO6Acu2TYqQrb9p3nMmR3qph0b6QwWS2PzVb7Yhvbetsf5ywc13Uzs/57jqlluRVIY+6GtqKYB5A6wncdoaLhWXmPAllviXc0OdtdcL4F5Kqf/CJDMlyOWcvJSJ/69YiGHM3SW1jxkDKNtcfPTq9lEJQOSLJI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080501; c=relaxed/simple; bh=36AusLO0pDxFRhzbhmkowXF4Cn8pQw3SfS8AJ1zFeOo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=eHL0ZTzP7kWD/AKF/7BYBrD+E5hNPoitDQytaeWEeYckkKSyUYZIqD2PHh1BappV2zHmvdOMTf0CXNa5OCVflICtcKSfJtw2cjNR4vUwJRgbH3b+kbqMHSeerejgf6RCsxjZlBHL3KAXjpqaBc5nwHAUJzRzHIxZoOMdKXsdJYg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CD2obr0a; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CD2obr0a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 842D01F000C7; Thu, 15 Oct 2026 16:07:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080480; bh=8Ud2Znr5W7y/xLuHTpF4M1rYyTf9+FphnA6xGQ/z7Ks=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=CD2obr0axs8FhpRcUB5Ocn0+jnAceHNutIpXQgX+lSym4HnRx2yPgZyvSrb/fiQ4s DysmRMSYtytGwsRc1DJdO5XDM7WHDnaNK6rytI7+mEpSSR/ywEZD7uM3eCyoIYlinT skNZAcTxHH9+eWiX9YdttVL5qE8jCFMh4IhrW9S3y6NnTXK5feC1M+YDjR83WWaiWW X9mKhmkzNjXunDWgbzHSri4+hf3NPCYy7h/1Z6Ig0E+89D/Lg9YNsZtw4B3qRCKgJt xPJYt0q+/wGDIOXag8ZGUeyx6T7IlRJnC3H9Y6rXVS5BV3KWq4eYIKiThS7fYPep2u UDfpWoLOVbwpg== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:12 +0200 Subject: [PATCH 06/10] mm/hugetlb: fix endless write fault on a leftover uffd bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-6-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , Chris Mason , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2767; i=david@kernel.org; h=from:subject:message-id; bh=vsY/j7SLFL5BWtxtbqOGInAFZOdZ8OaRvzchTAd21uY=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DKeF/jzQWTX4YzuQz8Xil02n/wjZcXlhVut+S89n 9Oh+malY0cpC4MYB4OsmCJLUPB9g5cv19VWu/Exw8xhZQIZwsDFKQAT+VnK8M/s4oWsK5uvTn7K dtH4e7XSXJH89fb5QTkO2ZtrLIx9jxow/BURPXnt9LfKPHvunq9MxTWG5+QncrFset3XoD77JuP St8wA X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik hugetlb_fault() resolves the uffd bit on a write fault only if the VMA is registered for userfaultfd write protection, and hugetlb_wp() bails out for any entry with the uffd bit set assuming hugetlb_fault() has already resolved it. When a read-only hugetlb entry with the uffd bit set is mapped in a VMA that is not registered for uffd-wp, a write fault to it never makes progress. If the access comes from the kernel, e.g. read(2) from /dev/zero into such page, the task spins in the page fault handler, ignores SIGKILL and keeps holding the locks taken by the system call. Such entries should not exist, but an unprivileged user can create them, for example with MADV_DONTNEED of a page protected with UFFDIO_RWPROTECT or with UFFDIO_COPY in MODE_WP racing with UFFDIO_UNREGISTER. Clear the uffd bit when the VMA is not registered for uffd-wp and let the fault proceed to hugetlb_wp(), like do_wp_page() does for regular pages. Note that a FOLL_FORCE write to a page protected with UFFDIO_RWPROTECT in a private VMA that was made PROT_NONE now drops the RWP protection of that page. Original fix generated by an LLM and sent in private by Josef. Fixes: 60d5b473d61b ("mm/hugetlb: fix uffd wr-protection for CoW optimizati= on path") Reported-by: Chris Mason Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik [rppt: massage commit message] Signed-off-by: Mike Rapoport (Microsoft) [ david: convert comment into a TODO ] Signed-off-by: David Hildenbrand (Arm) Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang --- mm/hugetlb.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index f8ad2efd472cb..c3823f1958568 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6184,15 +6184,19 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, stru= ct vm_area_struct *vma, goto out_ptl; =20 /* Handle userfault-wp first, before trying to lock more pages */ - if (userfaultfd_wp(vma) && huge_pte_uffd(huge_ptep_get(mm, vmf.address, v= mf.pte)) && + if (huge_pte_uffd(huge_ptep_get(mm, vmf.address, vmf.pte)) && (flags & FAULT_FLAG_WRITE) && !huge_pte_write(vmf.orig_pte)) { - if (!userfaultfd_wp_async(vma)) { + if (userfaultfd_wp(vma) && !userfaultfd_wp_async(vma)) { spin_unlock(vmf.ptl); hugetlb_vma_unlock_read(vma); mutex_unlock(&hugetlb_fault_mutex_table[hash]); return handle_userfault(&vmf, VM_UFFD_WP); } =20 + /* + * TODO: fix all cases where uffd PTE bits remain in VMAs that + * are no longer registered with uffd. + */ vmf.orig_pte =3D huge_pte_clear_uffd(vmf.orig_pte); set_huge_pte_at(mm, vmf.address, vmf.pte, vmf.orig_pte, huge_page_size(hstate_vma(vma))); --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0E7C55C1DE; Thu, 15 Oct 2026 16:08:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080502; cv=none; b=IL00LMzDkB3mB9eOONWeJbpt+it/lGtP591NiKimPifY4/S/f9EbvPstKam1Fs4LhaWIhmWKil7tEnP+/fZgM8m9R+CfQC21/2ACuiCgk5PCQulyo8aP52GThGA/2HTmRMsUm10nbbe/LdzsX8Le9u+RxCOGPkaV26QI3doRalU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080502; c=relaxed/simple; bh=+A1Chphb2VITOuNoz7RmBYZYcGXcwS2W5/AbSTwZtoE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=gB2us4l6eD/JweJMO678xFtY7rKdbrG/fLMWbv8s7klV2A8oDbVDcgnC6RFQ9r8/8Ki1fizqyrEnJ0k4NTkg48BG7jBbVQqw865MKschSifarJczD4nTeyprk4Z2yIJk7JDK9tcPIySQ6yE6s0lcgmASBp2zWNU05dDbbwEH8ZM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZYcxpNIF; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZYcxpNIF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C3A01F000CC; Thu, 15 Oct 2026 16:08:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080487; bh=eqtt2G7yriEeHnOR1/BbpfoTCAOmwPLLgIR0/nLFghI=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=ZYcxpNIFmgCQLbJ6gKyzpvUn7tozj4+2u7vUUUL+7Aqo1W3aYwEw8PGzXGi32Wvij OxjNg5lRcSvx811juXHVi5R43K/h+tHrxDIlWq4X7woi2AfJUMzhFRAM2hvfFtkqAc zo1PaPqXFL06M+UnAh0E10nXPAWC5GOWrIDWwCBDSEX2O+06CC6NEhnfIbS0hnieTX ygopodw7SUNSJ4DHMKzIxtUJjGU0YfKJdrU5OVMPuS0ae4AEemAEMeClPSsaJvuRbS clwz5u8Lqxs+Z3nIy5gK+H49YplBh0PH9ilp20xalypFnd30cBVNro5R+d4Qif+PfV NzPfB0acVJLxw== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:13 +0200 Subject: [PATCH 07/10] mm/hugetlb: tolerate uffd bits set without uffd for PROT_NONE PTEs Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-7-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1793; i=david@kernel.org; h=from:subject:message-id; bh=+A1Chphb2VITOuNoz7RmBYZYcGXcwS2W5/AbSTwZtoE=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DJulRZwuF5+1XCm2AsPcXa1rWLN5dPLRQr/rm6o4 twZuNG3o5SFQYyDQVZMkSUo+L7By5fraqvd+Jhh5rAygQxh4OIUgIlEuTIybOy203dTeec342v3 Tp8/l9aVRk/yeS9ffmqX+DW27kcHNjD8FXjetnKq72OJ1qzn277qy8govLZy/bnx1b29+vedTs5 z4gcA X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A The whole uffd handling when a VMA is unregistered from UFFD is shaky: there are still some scenarios where we might have stale uffd PTE bits in VMAs no longer registered for UFFD, which confuses other code. Let's just tolerate that for now and simply clear the PTE bit. Add a TODO to really clean up any uffd leftovers when unregistering a VMA from userfaultfd. The handling is now more similar to what we have in handle_pte_fault(). Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFF= DIO_REGISTER_MODE_RWP") Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand (Arm) Acked-by: Kiryl Shutsemau (Meta) Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang --- mm/hugetlb.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index c3823f1958568..ba6860b9b7f4c 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6127,16 +6127,20 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, stru= ct vm_area_struct *vma, * NUMA hinting), so let normal hugetlb fault handling proceed. */ if (pte_protnone(vmf.orig_pte) && vma_is_accessible(vma) && - userfaultfd_rwp(vma) && huge_pte_uffd(vmf.orig_pte)) { + huge_pte_uffd(vmf.orig_pte)) { spinlock_t *ptl; pte_t pte; =20 /* Sync: drop hugetlb locks before blocking in handle_userfault() */ - if (!userfaultfd_rwp_async(vma)) + if (userfaultfd_rwp(vma) && !userfaultfd_rwp_async(vma)) return hugetlb_handle_userfault(&vmf, mapping, VM_UFFD_RWP); =20 ptl =3D huge_pte_lock(h, mm, vmf.pte); pte =3D huge_ptep_get(mm, vmf.address, vmf.pte); + /* + * TODO: fix all cases where uffd PTE bits remain in VMAs that + * are no longer registered with uffd. + */ if (pte_protnone(pte) && huge_pte_uffd(pte)) { unsigned int shift =3D huge_page_shift(h); =20 --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D4EB559301; Thu, 15 Oct 2026 16:08:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080510; cv=none; b=Ol7sZT2syrwOPE7Mcq75o+h+60u10DjxKJw8YUMXNbbaECc5YHAejDJ5SONxehf2ALJjZxHHt+wOtmC6AFTMs1UQ++OQnV413GYT8vyHa4iibw0dDXw3LqBpnmU/lWVulOWQzZrsSnYQGqCDOqTrZ3E12DxPOWx8W5ZpGx3ViIk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080510; c=relaxed/simple; bh=ofcXbd6OOZoV/XLvMGg3PkUCMySCCrJuOQSO/eipRzw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=KM5589mWEEQI3lSIMOfgeXk/L5pWETMZNnSH+Xjjq3PgAH3BKYSlKVXQwZEFLaAGuRn4tiOvUCCklZIwaUztpcdPPNSP0FkHMUsVKj3dKRHP2kxTTacF/xfdAmkugmYu9z2u/vKNnOMPcnBbjK6jvJzzJb6OHCxoKwik9qgt94s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fYhfvFO4; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fYhfvFO4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B770A1F000C4; Thu, 15 Oct 2026 16:08:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080493; bh=3afvpKZmu+aKIyTGjKM2wG2gBoeR2hpYzLmhDcjm3gw=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=fYhfvFO435HJX8G2tJtP76UAXmJ91Nqa2hGQgcoVIF+DmlQd1+edSNcaE1eEqpnvg slM//rKzJmgasqG4T3BL8RHQwMQn7VfrN/UPyCvclOS6KJ5zuXQcJcgL2EIsAUCIy1 +WE8HwVO/tfCMQ7iqK//NkgCsprNmQ6irdFK4X6ROpiLwhn7QRz8ZL4dYlFDe1GRc/ YhOk4ISazQ9WQfsOxGSynufEw9x+vERdRgx4ENL4OqQwd5dWVDS+Zz7dWB0MZ7rlWy hsz2tsA2CD7DotS78D5FBwfpxg8jVm5OFin/K4HDru4o6SZ+EJryWcMmEpvlmqv5tf ea2VqumbPfPtw== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:14 +0200 Subject: [PATCH 08/10] mm/hugetlb: tolerate UFFD_WP markers outside uffd-wp VMAs Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-8-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1330; i=david@kernel.org; h=from:subject:message-id; bh=ofcXbd6OOZoV/XLvMGg3PkUCMySCCrJuOQSO/eipRzw=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DKO/u4dbn2Vryjmo2WmyN2iOelftGYEZC9wuDY90 WSiiHR9RykLgxgHg6yYIktQ8H2Dly/X1Va78THDzGFlAhnCwMUpABPZ3crwT2ESC8MXne43+r4x hk+0nC/qmUf0JDC8qko3dEoXW6yRzfC/sHDFvMK5Jk+S43JFfEuiegWWbtqYekwm2/3cBq47233 4AA== X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A UFFD PTE bit handling is a bit like swiss cheese, in particular with recently added RWP mode. Having uffd-wp markers outside uffd-wp VMAs already confused this code in the past and resulted in uffd-pte bits confusing other code later. Let's play safe and just ignore these markers in hugetlb_no_page(), not silently propagating the uffd-wp PTE bit. Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFF= DIO_REGISTER_MODE_RWP") Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand (Arm) Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang --- mm/hugetlb.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index ba6860b9b7f4c..1548a6156206b 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5939,8 +5939,11 @@ static vm_fault_t hugetlb_no_page(struct address_spa= ce *mapping, /* * If this pte was previously wr-protected, keep it wr-protected even * if populated. + * + * TODO: fix all cases where uffd-wp markers remain in VMAs that are no + * longer registered with uffd. */ - if (unlikely(pte_is_uffd_wp_marker(vmf->orig_pte))) + if (unlikely(userfaultfd_wp(vma) && pte_is_uffd_wp_marker(vmf->orig_pte))) new_pte =3D huge_pte_mkuffd(new_pte); set_huge_pte_at(mm, vmf->address, vmf->pte, new_pte, huge_page_size(h)); =20 --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CAAB53A896; Thu, 15 Oct 2026 16:08:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080514; cv=none; b=INwDISzZC0o+1KxuhABzAWu/lUaF7PavK2okvobUOTh/V3LJv463MO6PEvPfSrj3AvbI/0R8OqMpNDZJzo8hfvY0nLVRdCiSuRx/bIa6iwFedpLCvFUs9wbmYGScwwdVFTSH1qSBY7E2zLDFelHwLdCALB2TiTGAN3uQIRjYGl8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080514; c=relaxed/simple; bh=H0mRtHiREZR/wJfbvEOj3l9Hd/kFzFDOFJn7HQzzBYQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=gAfi3wCwBkDfHL7QEZShSy8E9A37hvbsjsVdhitp0gxAOJNp+l0eQeZE1cy5Q6mzhXx2sDFOK/J5/cVx0ka79p+P6YRq7PEK3UzAeRqUV5nJ2ZBe8dqnqKhaoIj6ATQSRii2zbgmDjx7ycAGhkXZ6/7JdmLTo4b9sEmxNnZ/6e0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IpWmW2p0; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IpWmW2p0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 020211F000C5; Thu, 15 Oct 2026 16:08:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080500; bh=luu9zceebiAM3DcgabjNhnEA73HFyTTMwHsaVP8GP7s=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=IpWmW2p0cOKas78pJQq1fPzYf4OjZG1D5/E4uGVb/sSKqnGO8zzcFpOAMCj8r8Y/j 0fwISAtT3NHdyUMidHHvUFlN1Ohz3zEfITaeqcVWXSZ9700SpEyGIoPz4xLl9I0pHu VZBaNezmk6pDEjLmgMsWOoTiGpsG8WEdR5ClhfEbOexU1Ev8s3wlE3q9Tkl81ZXpoG 0YtuMfNIq2fs5QkozUjwOKDOzPEL6e/QBoeaBm+P4umBvL3e//p62h/ezUx6VvuyNp 8LnNu/FcW0+Joug79ZWYKFiCnW7+t/ZW068LrHoTdTP/sWaR//pp2AGA7dByV03Atv 4GfSjSlq9VMRg== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:15 +0200 Subject: [PATCH 09/10] mm/hugetlb: don't leave a uffd-wp marker when zapping an RWP entry Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-9-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , stable@vger.kernel.org, Chris Mason X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2705; i=david@kernel.org; h=from:subject:message-id; bh=jDtJa/vbrcghzS+kebnll5J1z6JL9nvmr5+IgGhx8P8=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DI5dFov+la3mt9qM5ODbX/Yn6erNG2ukU4xN+8vP uv78NunjlIWBjEOBlkxRZag4PsGL1+uq61242OGmcPKBDKEgYtTACZycwkjw6O/8w7p9l0VffTL brFP0ttta0IMbO++/Gm6LHSF1dSsoisM/93Ut/a3rmRmX2n/dGrndpWZgcG1Tx9VnVFPu6yx3Ke ekx8A X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik An entry that is protected with UFFDIO_RWPROTECT is PAGE_NONE with the uffd bit set, the bit that userfaultfd write protection uses too. When __unmap_hugepage_range() zaps an entry with that bit it leaves a PTE_MARKER_UFFD_WP behind, whatever the VMA is registered for. In a VMA registered with UFFDIO_REGISTER_MODE_RWP that marker means nothing. The next fault has hugetlb_no_page() turn it into a present, read-only entry with the uffd bit. That is not an RWP entry, since it is not PAGE_NONE, and the VMA has no VM_UFFD_WP (the two modes can not be registered together). An earlier fix solved some side effects, now just stop the zap from wrongly installing a marker. Leave a marker only if the VMA is registered for write protection, both for present and for non-present entries. The zap of ordinary page tables has the same test, in cond_install_uffd_wp_ptes(), and hugetlb_change_protection() says that "uffd_rwp does not install markers". After a zap the range of an RWP VMA is simply empty, as it is for anonymous memory and shmem. Nothing changes for VMAs with VM_UFFD_WP. In a VMA that is not registered at all a leftover uffd bit or marker is now dropped by the zap and no longer kept alive. Original fix generated by an LLM and sent in private by Josef. Fixes: 2d427bb01639 ("mm/userfaultfd: add RWP fault delivery and expose UFF= DIO_REGISTER_MODE_RWP") Cc: stable@vger.kernel.org Reported-by: Chris Mason Signed-off-by: Josef Bacik [ david: a bit of description overhaul+simplification ] Signed-off-by: David Hildenbrand (Arm) Acked-by: Kiryl Shutsemau (Meta) Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Lance Yang --- mm/hugetlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 1548a6156206b..fb51f7d02cebf 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5267,7 +5267,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, s= truct vm_area_struct *vma, * drop the uffd-wp bit in this zap, then replace the * pte with a marker. */ - if (pte_swp_uffd_any(pte) && + if (userfaultfd_wp(vma) && pte_swp_uffd_any(pte) && !(zap_flags & ZAP_FLAG_DROP_MARKER)) set_huge_pte_at(mm, address, ptep, make_pte_marker(PTE_MARKER_UFFD_WP), @@ -5303,7 +5303,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, s= truct vm_area_struct *vma, if (huge_pte_dirty(pte)) folio_mark_dirty(folio); /* Leave a uffd-wp pte marker if needed */ - if (huge_pte_uffd(pte) && + if (userfaultfd_wp(vma) && huge_pte_uffd(pte) && !(zap_flags & ZAP_FLAG_DROP_MARKER)) set_huge_pte_at(mm, address, ptep, make_pte_marker(PTE_MARKER_UFFD_WP), --=20 2.43.0 From nobody Fri Oct 23 22:16:13 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06E5F3EFD24; Thu, 15 Oct 2026 16:08:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080520; cv=none; b=Gnh5vpE/mRy0dg6SZgP1HhK1w3XjV660KPKp1MJnprdMC+C4xTQSYEv2zyJRxasae17ZtwD1kuBoB3aduDq8nOj/P0N5eUtCYkZHP28JBY24FLlK04v/GDmqVaP+4Y+s+Wz2nKz+NR25p/f1cekpMBzTjD2/zhijapK2b//9TOY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792080520; c=relaxed/simple; bh=xzUoLGsOY/4424/eZSx1vu8LhLt89f41pteXNyOKue8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ut6m6/Gb9N4rcyPDlle3kG2XybfQmge9GLtH1TVJTa5VD8FzoRW1B9MCrQjZKhPrDHnXGH4l7lHX1yzvboyDCHSrzopcifyhH1IlzXdNBx/ok2DXlcVnkdQ0fXBl8aogFltSNVq6vGnVXphyviItGGWe/YTmglcRqmyNnS7z+Wg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S0BiqyM1; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S0BiqyM1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D18C91F000C6; Thu, 15 Oct 2026 16:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792080506; bh=aNBJ012Mx6kfcvUBOVNjCydGf++Y8d3EAS1qqSl0elI=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=S0BiqyM1EikbU5FSP5gpgmgVDBpDGZBYWODwAV1Ic3pNA1VmXdIOuQKrAshlqR3Qh wVP9C6RR2rBriogLU/+ZEYh5q71OPq3xSELDt/+3lXBBdtWTc62aIKPCFWPSZq0FTf y6+9+NgDq6+rinyM3/++iSFdepuLfZS1iXvRjqoHz/LLqcH2SBHFMQrbsWVD9qMVGX Npc6IX+bOez0lyR1YTFpqRQ4DunIPt8k24kjrcvhVpo20A5FzpUgPqMMA4R9ttx4ME T2oHNK+l1Aj19WPcDh0pts0jgnqhIXtUncc3/s8gfI4+GuDEuAybw/NORTIoyH32aV s37ewwY6xA1WQ== From: "David Hildenbrand (Arm)" Date: Thu, 15 Oct 2026 18:07:16 +0200 Subject: [PATCH 10/10] mm/mremap: fix calling fixup_hugetlb_reservations() on the wrong VMA Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261015-urgent_fixes-v1-10-42796911043b@kernel.org> References: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pedro Falcato , Muchun Song , Oscar Salvador , Miaohe Lin , Naoya Horiguchi , Adam Litke , Mel Gorman , Rik van Riel , Peter Xu , "Kiryl Shutsemau (Meta)" , "Mike Rapoport (Microsoft)" , "Liam R. Howlett" , Josef Bacik Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1190; i=david@kernel.org; h=from:subject:message-id; bh=xzUoLGsOY/4424/eZSx1vu8LhLt89f41pteXNyOKue8=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIu/DIpVItrO/T+XsDxVxsfyqpM+Td5ovDErdGyr3ZqT jh2/utCvo5SFgYxDgZZMUWWoOD7Bi9frqutduNjhpnDygQyhIGLUwAmsuEDI8OUOOH5+WJBQm+u xXNcnr3e6QdPid4Hqb8/ltfaOHxx2GfP8D+9qqk/RG3zpy9q+ZLHG72S6nZxFrUa31m/csHRGGu dbewA X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A In case we fail to move the page tables, for example, because we fail to allocate a page table, we actually keep the old VMA. Calling fixup_hugetlb_reservations() on the old VMA is wrong. Fix it by just calling it on the VMA that will be removed. The user-visible impact is that the VMA loses its reservations, meaning that the existing reservations get stranded (leaked) and new hugetlb folios that are getting allocated in the VMA cannot make use of the reservations, failing these allocations. Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") Cc: stable@vger.kernel.org Reviewed-by: Lorenzo Stoakes (ARM) Signed-off-by: David Hildenbrand (Arm) Acked-by: Muchun Song Reviewed-by: Lance Yang --- mm/mremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/mremap.c b/mm/mremap.c index 444f37d7cd28e..ace0c6a343b1b 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -1345,7 +1345,7 @@ static int copy_vma_and_data(struct vma_remap_struct = *vrm, mremap_userfaultfd_prep(new_vma, vrm->uf); } =20 - fixup_hugetlb_reservations(vma); + fixup_hugetlb_reservations(vrm->vma); =20 *new_vma_ptr =3D new_vma; return err; --=20 2.43.0