From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Adam Litke <agl@us.ibm.com>, Mel Gorman <mel@csn.ul.ie>,
Rik van Riel <riel@surriel.com>, Peter Xu <peterx@redhat.com>,
"Kiryl Shutsemau (Meta)" <kas@kernel.org>,
"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Josef Bacik <josef@toxicpanda.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"David Hildenbrand (Arm)" <david@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH 02/10] mm/hugetlb: fix use-after-free of a new anon folio
Date: Thu, 15 Oct 2026 18:07:08 +0200 [thread overview]
Message-ID: <20261015-urgent_fixes-v1-2-42796911043b@kernel.org> (raw)
In-Reply-To: <20261015-urgent_fixes-v1-0-42796911043b@kernel.org>
From: Josef Bacik <josef@toxicpanda.com>
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=0|zone=2)
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 sharing synchronization")
Cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
[ david: simplify+move comment ]
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
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_space *mapping,
ret = hugetlb_wp(vmf);
}
- 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_space *mapping,
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);
--
2.43.0
next prev parent reply other threads:[~2026-10-15 16:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 16:07 [PATCH 00/10] mm: various (urgent?) fixes David Hildenbrand (Arm)
2026-10-15 16:07 ` [PATCH 01/10] mm/vma: don't leak the commit charge on mmap failure David Hildenbrand (Arm)
2026-10-15 17:54 ` Pedro Falcato
2026-10-15 18:53 ` David Hildenbrand (Arm)
2026-10-16 8:34 ` Jose A. Perez de Azpillaga
2026-10-15 16:07 ` David Hildenbrand (Arm) [this message]
2026-10-16 7:16 ` [PATCH 02/10] mm/hugetlb: fix use-after-free of a new anon folio Muchun Song
2026-10-15 16:07 ` [PATCH 03/10] mm/hugetlb: fix use-after-free in hugetlb_mfill_atomic_pte() David Hildenbrand (Arm)
2026-10-16 7:18 ` Muchun Song
2026-10-15 16:07 ` [PATCH 04/10] mm/hugetlb: unmap the page where the other VMA maps it David Hildenbrand (Arm)
2026-10-16 9:49 ` Muchun Song
2026-10-15 16:07 ` [PATCH 05/10] mm/hugetlb: don't clear the resv_map of a VMA whose lock is held David Hildenbrand (Arm)
2026-10-16 9:52 ` Muchun Song
2026-10-15 16:07 ` [PATCH 06/10] mm/hugetlb: fix endless write fault on a leftover uffd bit David Hildenbrand (Arm)
2026-10-15 20:10 ` Lorenzo Stoakes (ARM)
2026-10-15 16:07 ` [PATCH 07/10] mm/hugetlb: tolerate uffd bits set without uffd for PROT_NONE PTEs David Hildenbrand (Arm)
2026-10-15 20:13 ` Lorenzo Stoakes (ARM)
2026-10-15 16:07 ` [PATCH 08/10] mm/hugetlb: tolerate UFFD_WP markers outside uffd-wp VMAs David Hildenbrand (Arm)
2026-10-15 19:47 ` Lorenzo Stoakes (ARM)
2026-10-15 16:07 ` [PATCH 09/10] mm/hugetlb: don't leave a uffd-wp marker when zapping an RWP entry David Hildenbrand (Arm)
2026-10-15 19:45 ` Lorenzo Stoakes (ARM)
2026-10-15 16:07 ` [PATCH 10/10] mm/mremap: fix calling fixup_hugetlb_reservations() on the wrong VMA David Hildenbrand (Arm)
2026-10-16 9:53 ` Muchun Song
2026-10-16 7:15 ` [PATCH 00/10] mm: various (urgent?) fixes Muchun Song
2026-10-16 7:40 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261015-urgent_fixes-v1-2-42796911043b@kernel.org \
--to=david@kernel.org \
--cc=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=josef@toxicpanda.com \
--cc=kas@kernel.org \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mel@csn.ul.ie \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®