From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) (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 021123D6689 for ; Wed, 5 Aug 2026 20:24:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785961496; cv=none; b=G8IqzH+GBuiIsFysAbByEJPhOF8WROk6BGfFHCZg8rnJNbrtYQt54b85IkEBM7aKJnzPXAyX5+VR2bgyhbgnNj0i2c0PiJnb4hbY54UOP93CCpF+okLHWHs6Swrff0Q7J1NkxlEKu9fubP8QT+SAW5RuDOuPjLovHJovU2XWS1I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785961496; c=relaxed/simple; bh=3ed+ZEE4C6m7CLeHEQo8Z3pmLNFWmg97mz+DYIfWKWM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GssjHIxVqszWHn2bpMKSjzIxmLVvFJGei2UiPmJjbH90foS7mAYPwD8VFEk8bY1r8iRfdhhydOEOiYC5uDBomoXkPSHGXOCTreto/eoi7lSYaWX2Rqo7epwzd7uwZBIAQq/hte5VPGjDkXZo5CqRBmG9PyozSvAt5tTPBFU77hY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=wB//v4fh; arc=none smtp.client-ip=91.218.175.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="wB//v4fh" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785961490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nEH2CoFwohGH5dxkOgSIARejt1oXPrA3YkjsFxuFaSs=; b=wB//v4fhgHnHncyhvD/4oDNstyL4uRWD5SeyhoV5/SCL+0CFsL+g6OC0LHzYfeH8TnY1WA tL8aw5Ly9b2wNmtOpP+ne6M/Y/xqG0xTeukDSMe0GjuWzvt55MZh6ccIZcG61pMmFRwa8L azRJxcsXIUPtJnn7JnyEBLpgnq820ho= From: Usama Arif To: Sourav Panda Cc: Usama Arif , muchun.song@linux.dev, osalvador@suse.de, akpm@linux-foundation.org, david@kernel.org, surenb@google.com, fvdl@google.com, gthelen@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] mm/hugetlb_cma: Fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio Date: Wed, 5 Aug 2026 13:24:42 -0700 Message-ID: <20260805202444.1573218-1-usama.arif@linux.dev> In-Reply-To: <20260726072935.3513996-1-souravpanda@google.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Sun, 26 Jul 2026 07:29:34 +0000 Sourav Panda wrote: > 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() via > alloc_gigantic_frozen_folio(). > > hugetlb_cma_alloc_frozen_folio() blindly dereferences the nodemask in > node_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask), > leading to a null pointer dereference kernel panic. > > Fix this by checking if nodemask is NULL in > hugetlb_cma_alloc_frozen_folio() and defaulting it to > node_states[N_MEMORY]. This allows hugetlb_cma allocations to fall > back to any node with memory, keeping behavior consistent with > alloc_contig_frozen_pages() and alloc_buddy_frozen_folio(). > > >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: > > 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 > > Fixes: eb02f14c4a2b ("mm/hugetlb: allow overcommitting gigantic hugepages") > Cc: stable@vger.kernel.org > Signed-off-by: Sourav Panda > --- > Changes in v4: > - Reverted the alloc_fresh_hugetlb_folio() cpuset snapshot approach from v3. > As Muchun Song pointed out, snapshotting cpuset_current_mems_allowed does > not prevent false-positive allocation failures without complex retry loops, > and alloc_contig_frozen_pages() / alloc_buddy_frozen_folio() already handle > NULL nodemasks safely internally. > - Handled NULL nodemask directly inside hugetlb_cma_alloc_frozen_folio() > by defaulting nodemask to node_states[N_MEMORY] (Option 2), keeping > HugeTLB allocators clean and consistent. > - v3: https://lore.kernel.org/linux-mm/20260705175119.440599-1-souravpanda@google.com/ > - v2: https://lore.kernel.org/linux-mm/20260704174930.2885785-1-souravpanda@google.com/ > - v1: https://lore.kernel.org/linux-mm/20260702215713.627941-1-souravpanda@google.com/ > > mm/hugetlb_cma.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/mm/hugetlb_cma.c b/mm/hugetlb_cma.c > index 39344d6c78d8..5744de0ceeb7 100644 > --- a/mm/hugetlb_cma.c > +++ b/mm/hugetlb_cma.c > @@ -34,7 +34,10 @@ struct folio *hugetlb_cma_alloc_frozen_folio(int order, gfp_t gfp_mask, > if (!hugetlb_cma_size) > return NULL; > > - if (hugetlb_cma[nid]) > + if (!nodemask) > + nodemask = &node_states[N_MEMORY]; Hi Sourav, hmm what if cpuset.mems only allows allocation from node 0, and hugetlb CMA is only available on node 1. This will no now allow allocating a gigantic page on node 1 when its explicitly not allowed? Would it not be better to check cpuset as well? Thanks, Usama > + > + if (hugetlb_cma[nid] && node_isset(nid, *nodemask)) > page = cma_alloc_frozen_compound(hugetlb_cma[nid], order); > > if (!page && !(gfp_mask & __GFP_THISNODE)) { > -- > 2.55.0 >