From mboxrd@z Thu Jan 1 00:00:00 1970 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 9147F245008 for ; Tue, 28 Jul 2026 00:57:05 +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=1785200226; cv=none; b=I2o7I57ZQCRkZkBHXlZ6Mq7GfZH4maIs4IhOVfmltw8SnqLIV9dlXJ4Q8H0fkijWg4o/2i5VK1oixf9keiNR4Soyjp1Tr8FqfcbYp/+lgWTuN2WNXuFjG/asKUPII4fsxUnUl5k+u4J1uIdyVajY92GFi8i91Zs6xOWCviFu8GE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785200226; c=relaxed/simple; bh=ZGHeVdU+kCdZCBK48djoNND+t5+utpWlV7ZN8Z6yGSw=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=tioyHIwyuMTAZa5Bb/rktepJIy+qfNnQiUZnAdEZrKRdqqy1CMsOESr3EDa+dh+ovK7QV5YYcEwr1YUnYhgdtiU4wA6QPkuZDTSb++bELj6UiANfHDWr7BGVYhpYpXC1lqGipJB1AUriWmLgcqd3/uOmuwCWcoRJlmMyaSUf3RQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=V++APQda; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="V++APQda" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10F4C1F000E9; Tue, 28 Jul 2026 00:57:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1785200225; bh=9XKvUBtNz8mAqieUy7X2gVA3uFyDYAi8JFETA7NGeYQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=V++APQdav59a96D19Bw6Q+BKElEnxWZXtnDS0ZWNXgt2ft1PMcLZYLfkE85fSRbpk +tHp+5bqUDzoTZ4QBZY3lUItBQnMcwHEcu2Ii5rwe7rHBs8qZMJcu8XAjLz436egUb Qg0UbksZCPLgM8IcUqWepEXgStmbMeeh/sj5ayqY= Date: Mon, 27 Jul 2026 17:57:04 -0700 From: Andrew Morton To: Sourav Panda Cc: muchun.song@linux.dev, osalvador@suse.de, david@kernel.org, surenb@google.com, fvdl@google.com, gthelen@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Usama Arif , Shakeel Butt , Kefeng Wang Subject: Re: [PATCH v4] mm/hugetlb_cma: Fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio Message-Id: <20260727175704.0e4ccd4a6201435a6284d260@linux-foundation.org> In-Reply-To: <20260726072935.3513996-1-souravpanda@google.com> References: <20260726072935.3513996-1-souravpanda@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit 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 Thanks. I'll queue this as a hotfix while we await review. > Fixes: eb02f14c4a2b ("mm/hugetlb: allow overcommitting gigantic hugepages") It's a good idea to cc the people who were involved in the to-be-fixed patch - Author and Reviewers. > > ... > > --- 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]; > + > + 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