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 E51223264C7
	for <linux-kernel@vger.kernel.org>; Thu,  2 Jul 2026 23:24:16 +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=1783034657; cv=none; b=MHivYV31IxT4hHPLXjQTS8HiOYmU0bUjfZ5NJzA8i17xntB8cPvsGn6OlOW5awFV99BDpOQbJ1tbB+feVFNiq1Ytc0FP14S3SqWIB4V1rw5lXO17NwqWDOpXeU9Zvtf8COdvMiLIAT4FE5TWcP5ntXgbK5O5Zt9270Q22vQ6zo4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1783034657; c=relaxed/simple;
	bh=bbPAgei/9AqGCWV0le+a2iH1O+oDhRtMApei7VYE1WA=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=KXai8EjAMGT6qqWInHLx5ilujCHXzFTya3vWdVOVqp+h9xgblTTASClLYK/X01/SIMcR20SHRGkygDbxEEvx9CM7/o+dhL8Bp5OFe32/uoRKNLLsgTnIO8Ir7/Q6Tp1/Hqw/ZKa0aFeC71MR4xdkui/VyhbTW+nT6Nw7wLu76TI=
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=vXlGOuxj; 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="vXlGOuxj"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25FC41F000E9;
	Thu,  2 Jul 2026 23:24:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=linux-foundation.org; s=korg; t=1783034656;
	bh=9nAR8YU/o7p8fJF07xiO/e+rL8kilUhTDLlZLPJMmsc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=vXlGOuxjAvqEmI64WduaeIZ77NBbEBBdhXc6AY30OAe0HySgDgikjryaQMk2M1Tva
	 +1Ciw/6Wx0wuT84veROJHv6eF1uBMva33ce93pR7IlQUFIP2bpgtuSk/YxrY5C+SoS
	 X5ntIropOkKNGm+LFWRO3iCOEiOIWzMVZKBBZmhY=
Date: Thu, 2 Jul 2026 16:24:15 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Sourav Panda <souravpanda@google.com>
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
Subject: Re: [PATCH] mm/hugetlb: Fix null pointer dereference of nodemask in
 hugetlb_cma_alloc_frozen_folio
Message-Id: <20260702162415.142571f4d8c43aa4b95b9f7c@linux-foundation.org>
In-Reply-To: <20260702215713.627941-1-souravpanda@google.com>
References: <20260702215713.627941-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: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu,  2 Jul 2026 21:57:13 +0000 Sourav Panda <souravpanda@google.com> wrote:

> alloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to
> hugetlb_cma_alloc_frozen_folio() as a fallback to allocate from all
> nodes. In this case, hugetlb_cma_alloc_frozen_folio() blindly
> dereferences it in for_each_node_mask(), leading to a null pointer
> dereference.
> 

oh.

> Fix this by checking if nodemask is NULL and defaulting to
> node_states[N_MEMORY] if it is.
> 
> --- a/mm/hugetlb_cma.c
> +++ b/mm/hugetlb_cma.c
> @@ -34,6 +34,9 @@ struct folio *hugetlb_cma_alloc_frozen_folio(int order, gfp_t gfp_mask,
>  	if (!hugetlb_cma_size)
>  		return NULL;
>  
> +	if (!nodemask)
> +		nodemask = &node_states[N_MEMORY];
> +
>  	if (hugetlb_cma[nid])
>  		page = cma_alloc_frozen_compound(hugetlb_cma[nid], order);

It is possible to hit this with any known testcase?

If not, why not.  I smell the smell of dead code somewhere?


Sashiko said things:
	https://sashiko.dev/#/patchset/20260702215713.627941-1-souravpanda@google.com


Ackerly's "mm: hugetlb: move mpol interpretation out of
alloc_buddy_hugetlb_folio_with_mpol()" made big changes to
alloc_buddy_hugetlb_folio_with_mpol():
https://lore.kernel.org/20260702-hugetlb-open-up-v4-2-d53cefcccf34@google.com.

If this bug is real then it would be better to stage your fix ahead of
Ackerly's series.  Possibly with a cc:stable.  Then I can redo
Ackerly's patch on top and we'll need to check that this bug isn't
reintroduced.