All of lore.kernel.org
 help / color / mirror / Atom feed
* [to-be-updated] mm-hugetlb-fix-null-nodemask-in-alloc_fresh_hugetlb_folio.patch removed from -mm tree
@ 2026-07-28  0:53 Andrew Morton
  0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2026-07-28  0:53 UTC (permalink / raw)
  To: mm-commits, usamaarif642, surenb, stable, osalvador, muchun.song,
	gthelen, fvdl, david, souravpanda, akpm


The quilt patch titled
     Subject: mm/hugetlb: fix null nodemask in alloc_fresh_hugetlb_folio
has been removed from the -mm tree.  Its filename was
     mm-hugetlb-fix-null-nodemask-in-alloc_fresh_hugetlb_folio.patch

This patch was dropped because an updated version will be issued

------------------------------------------------------
From: Sourav Panda <souravpanda@google.com>
Subject: mm/hugetlb: fix null nodemask in alloc_fresh_hugetlb_folio
Date: Sun, 5 Jul 2026 17:51:19 +0000

alloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to
alloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes.  If
order is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL
nodemask down to hugetlb_cma_alloc_frozen_folio() which blindly
dereferences it in for_each_node_mask(), leading to a null pointer
dereference.

Similarly, if the CMA allocation fails, the fallback
alloc_contig_frozen_pages() is also called with a NULL nodemask, which may
cause issues.

Fix this by explicitly checking if nodemask is NULL in
alloc_fresh_hugetlb_folio() and defaulting to cpuset_current_mems_allowed.
This ensures that both the CMA and contiguous allocators receive a valid
nodemask safely using a seqcount loop to prevent torn reads.

From a userspace perspective, this bug allows an unprivileged user to
crash the kernel (trigger a panic) by requesting a gigantic hugepage
allocation with MPOL_PREFERRED_MANY on a system where CMA is only
configured on a subset of NUMA nodes.

This can be reproduced by booting a VM with two NUMA nodes, restricting
CMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G
hugepages=0), and running a program that allocates a 1GB hugepage area
without reserving, restricts allocation to Node 0 using mbind() with
MPOL_PREFERRED_MANY, and triggers a page fault:

  void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE,
                   MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB |
                   MAP_HUGE_1GB | MAP_NORESERVE, -1, 0);
  unsigned long nodemask = 1; /* Node 0 */
  mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask,
        sizeof(nodemask) * 8, 0);
  memset(ptr, 0, 1UL << 30); /* Trigger fault */

This results in a NULL pointer dereference:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  Oops: Oops: 0000 [#1] SMP NOPTI
  RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120
  Call Trace:
   <TASK>
   only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160
   alloc_surplus_hugetlb_folio+0x6d/0x100
   alloc_hugetlb_folio+0x3c5/0x660
   hugetlb_no_page+0x3d9/0x650

Additionally, this patch adds a missing node_isset(nid, *nodemask) check
in hugetlb_cma_alloc_frozen_folio() to ensure the initial node allocation
attempt respects the memory policy.

Link: https://lore.kernel.org/20260705175119.440599-1-souravpanda@google.com
Fixes: eb02f14c4a2b ("mm/hugetlb: allow overcommitting gigantic hugepages")
Signed-off-by: Sourav Panda <souravpanda@google.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/hugetlb.c     |   12 ++++++++++++
 mm/hugetlb_cma.c |    2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

--- a/mm/hugetlb.c~mm-hugetlb-fix-null-nodemask-in-alloc_fresh_hugetlb_folio
+++ a/mm/hugetlb.c
@@ -1864,6 +1864,18 @@ static struct folio *alloc_fresh_hugetlb
 		gfp_t gfp_mask, int nid, nodemask_t *nmask)
 {
 	struct folio *folio;
+	nodemask_t local_node_mask;
+
+	if (!nmask) {
+		unsigned int cpuset_mems_cookie;
+
+		do {
+			cpuset_mems_cookie = read_mems_allowed_begin();
+			local_node_mask = cpuset_current_mems_allowed;
+		} while (read_mems_allowed_retry(cpuset_mems_cookie));
+
+		nmask = &local_node_mask;
+	}
 
 	folio = only_alloc_fresh_hugetlb_folio(h, gfp_mask, nid, nmask, NULL);
 	if (folio)
--- a/mm/hugetlb_cma.c~mm-hugetlb-fix-null-nodemask-in-alloc_fresh_hugetlb_folio
+++ a/mm/hugetlb_cma.c
@@ -34,7 +34,7 @@ struct folio *hugetlb_cma_alloc_frozen_f
 	if (!hugetlb_cma_size)
 		return NULL;
 
-	if (hugetlb_cma[nid])
+	if (hugetlb_cma[nid] && node_isset(nid, *nodemask))
 		page = cma_alloc_frozen_compound(hugetlb_cma[nid], order);
 
 	if (!page && !(gfp_mask & __GFP_THISNODE)) {
_

Patches currently in -mm which might be from souravpanda@google.com are

mm-hugetlb_cma-fix-null-nodemask-dereference-in-hugetlb_cma_alloc_frozen_folio.patch
mm-hugetlb_cma-support-percentage-based-hugetlb_cma-reservation.patch


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2026-07-28  0:53 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-28  0:53 [to-be-updated] mm-hugetlb-fix-null-nodemask-in-alloc_fresh_hugetlb_folio.patch removed from -mm tree Andrew Morton

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.