Re: [PATCH] mm/hugetlb: Fix null pointer dereference of nodemask in hugetlb_cma_alloc_frozen_folio

[Andrew Morton]

On Thu,  2 Jul 2026 21:57:13 +0000 Sourav Panda <souravpanda@xxxxxxxxxx> 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@xxxxxxxxxx


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@xxxxxxxxxx.

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.