Re: [PATCH v2 10/13] mm: Remove __alloc_pages_node()

["Brendan Jackman" <brendan.jackman@linux.dev>]

On Mon Jun 22, 2026 at 10:17 AM UTC, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The patch leaves `__folio_alloc_node()` exposed to the exact same CPU hotplug out-of-bounds vulnerability that justified the removal of `__alloc_pages_node()`.
> --
>
> commit b690a6726aee701f88a87b35d2db8bfbfa39bc05
> Author: Brendan Jackman <jackmanb@google.com>
>
> mm: Remove __alloc_pages_node()
>
> This patch removes __alloc_pages_node() because its usage with cpu_to_node()
> can return NUMA_NO_NODE during CPU hotplug, bypassing validation and causing
> out-of-bounds accesses on NODE_DATA().
>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index cdf95a9f0b87c..7edcc2e0be9ce 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -278,21 +278,6 @@ static inline void warn_if_node_offline(int this_node, gfp_t gfp_mask)
>>  	dump_stack();
>>  }
>>  
>> -/*
>> - * Allocate pages, preferring the node given as nid. The node must be valid and
>> - * online. For more general interface, see alloc_pages_node().
>> - */
>> -static inline struct page *
>> -__alloc_pages_node_noprof(int nid, gfp_t gfp_mask, unsigned int order)
>> -{
>> -	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
>> -	warn_if_node_offline(nid, gfp_mask);
>> -
>> -	return __alloc_pages_noprof(gfp_mask, order, nid, NULL);
>> -}
>> -
>> -#define  __alloc_pages_node(...)		alloc_hooks(__alloc_pages_node_noprof(__VA_ARGS__))
>> -
>>  static inline
>>  struct folio *__folio_alloc_node_noprof(gfp_t gfp, unsigned int order, int nid)
>>  {
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does leaving
> __folio_alloc_node_noprof() exposed maintain the exact same CPU hotplug
> vulnerability that justified removing __alloc_pages_node()?
  ^^^^^^^^^^^^^ No, Sashiko-chan! Why are you disclosing this critical
	        vulnerability without an embargo!?!?!
>
> The commit message notes that passing the result of cpu_to_node() to the
> allocator can yield NUMA_NO_NODE if the CPU is hotplugged out, which
> bypasses validation and causes out-of-bounds accesses on NODE_DATA().
>
> Can this still happen with __folio_alloc_node()? For example, in
> net/sunrpc/svc.c, svc_prepare_thread() calls:
>
> rqstp->rq_scratch_folio = __folio_alloc_node(GFP_KERNEL, 0, node);
>
> with a potentially invalid node ID originating from cpu_to_node(). Should
> __folio_alloc_node() also be removed or updated to safely handle
> NUMA_NO_NODE?

Serious answer: this is discussed in the cover letter, leaving the
*folio* API untouched was deliberate.

(Not saying we _shouldn't_ make that change, but this patchset is
already pretty big and the __alloc_pages* changes had an ulterior
motive).