From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D397306B3B for ; Tue, 11 Aug 2026 05:29:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.72 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786426152; cv=none; b=kGctvGazRADf7lP8uJyGd80+Mlc4P5Nf8ndvA6oZbe4G7bJFIYKRJocLDw+oYZPuoNrWk0wT6pcgLG+EiZgo1XvVVbt4ajuTqJnZHceAV7lgxAEHNc1lAENFxJdzmla33N0a5EI/pfVaCMGZCtsXI7IlQ5taXFp047bxERJJvqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786426152; c=relaxed/simple; bh=0xXQV9nrXmDkma30+za+wBO87ifWBXqquWAGc+7+OV8=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=o1uVU7dThI+pelxVBnx0U4ypb7dGj2lJlHM7HpaHRxyyS/1Atl5PQALHjGgaVEZFTomObYRQgjd/MbTg04gO34ahdlvsVrrOBcew5zKQPTIIDg0Clk4pNTqf4CBLyRwHdBEOOirU38SdSMSyMOqi/w/KJInCTp+P2J1KBSEhgc8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--souravpanda.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=FdlgXaXS; arc=none smtp.client-ip=209.85.216.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--souravpanda.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FdlgXaXS" Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-38e7621655eso5006601a91.0 for ; Mon, 10 Aug 2026 22:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786426150; x=1787030950; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:mime-version:date:from :to:cc:subject:date:message-id:reply-to:content-type; bh=MNQl2P6LXAgXNrrea3Lx9Pop4FTZLY7ulqZAcPycpvg=; b=FdlgXaXSOJSPl39C21fFfLFD3BqhZbm2JkbpbRx1w21fIez9fvc5x1W5he+uJsBNtw jERTuGp7viCP5lI3gaZOQUm1i7ZzmX5Lif6RJSuLdo5VvPYViqxWJOkck8eRna9RyflD DExb5zJUIMWj1hE+AKIpmiql5+rYQqRo93c7/MlLsWD5nvREUSNvoDocssI4JMDQmE6O OvS8IXpN6qw1D0CZwrX5EOy8WZtQFfkDWqlTczgjxMPdWn0J814wRTlOekP3XHGzpdaT y2Ou/PDJ9UAxRO0N90S00Woetxesrj5O8U9XpgKls+J5sTn/MRnJFw7VTfaODDJHoSBS 8Bqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786426150; x=1787030950; h=content-type:cc:to:from:subject:message-id:mime-version:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=MNQl2P6LXAgXNrrea3Lx9Pop4FTZLY7ulqZAcPycpvg=; b=fuD6vd2tkMEaULwEzFKntJwwIjb46Ue6L7LddQjIMMtPiMBMA7JUuIqlGzLUdZATeK NPSMuhVxP0GvMtVfYmHFtPypKOxYx2kG1iLxAioF6WU45JjA2s1lu3BS4AqrGObJP7WU EyW+CgWHMEOnmdRKqmvdUvcIhGoD6YC01Y60BPfYeU5KA12hsMPLATXD1IEK04KsUB5F fl6EP7C6Hm0a+GQd3kOogpciFE2BsPQKPrJg72fdLvwmifNOYAcE4pxH+cGurzulvsoi WCKhNry1tzX6vB8wo9LxijznReD+wNSxx4u+35xKpeSUNJ9b2UnTpM15aJPHZD5BFgpN l3sg== X-Forwarded-Encrypted: i=1; AHgh+RoNQUGZ8Hbv488zdx0jPOhUA/VC9EniNiabA5TkdeZwiCbeUioAJwc6FDi9/PwVppDKrr6TXRa9fnQA7as=@vger.kernel.org X-Gm-Message-State: AOJu0YzqAYNH5cAec/35swYx60uYCBJovkKrkKhXRCM5lbMnJw4VjkB9 sZCuf26O8J7cWnlZDjw0TFh2LIgY9W1tdqM+nIEAab3pPOcpfXEf7pAjr5KMdXOjkthJ2tQtTEE 5AP0wcxn68mFwF+FBV3nIYeRL+g== X-Received: from pjva15.prod.google.com ([2002:a17:90a:d80f:b0:38f:19c9:2dad]) (user=souravpanda job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1b03:b0:381:11eb:d78e with SMTP id 98e67ed59e1d1-392ec5dc6d9mr755643a91.14.1786426150282; Mon, 10 Aug 2026 22:29:10 -0700 (PDT) Date: Tue, 11 Aug 2026 05:29:09 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog Message-ID: <20260811052909.475635-1-souravpanda@google.com> Subject: [PATCH v7] mm/hugetlb_cma: Fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio From: Sourav Panda To: muchun.song@linux.dev, osalvador@suse.de, akpm@linux-foundation.org Cc: usama.arif@linux.dev, shakeel.butt@linux.dev, wangkefeng.wang@huawei.com, anshuman.khandual@arm.com, david@kernel.org, surenb@google.com, fvdl@google.com, gthelen@google.com, hannes@cmpxchg.org, riel@surriel.com, sj@kernel.org, vbabka@suse.cz, mhocko@suse.com, bjackman@google.com, zi.yan@sent.com, souravpanda@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" 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(). Additionally, hugetlb_cma_alloc_frozen_folio() previously attempted allocation on hugetlb_cma[nid] without verifying if nid is included in the caller's nodemask. Adding a node_isset(nid, *nodemask) check ensures the initial preferred node allocation honors the memory policy / nodemask. However, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in node_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask), leading to a null pointer dereference kernel panic when nodemask is NULL. Fix this by checking if nodemask is NULL in hugetlb_cma_alloc_frozen_folio() and defaulting it to cpuset_current_mems_allowed. Enclose the allocation attempts within the cpuset seqcount retry loop so that if the cpuset changes concurrently during allocation, the attempts are retried using the updated nodemask. This ensures that the initial node check and fallback loop safely honor the task's cpuset without violating cpuset constraints or causing NULL pointer dereferences or unexpected allocation failures. >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 v7: - Removed local_node_mask stack variable as suggested by Muchun Song, setting nmask = &cpuset_current_mems_allowed directly to conserve stack space. - v6: https://lore.kernel.org/linux-mm/20260810230844.3778931-1-souravpanda@google.com/ - v5: https://lore.kernel.org/linux-mm/20260809043250.2917406-1-souravpanda@google.com/ - v4: https://lore.kernel.org/linux-mm/20260726072935.3513996-1-souravpanda@google.com/ - 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 | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/mm/hugetlb_cma.c b/mm/hugetlb_cma.c index 39344d6c78d8..3e22161686d2 100644 --- a/mm/hugetlb_cma.c +++ b/mm/hugetlb_cma.c @@ -3,6 +3,7 @@ #include #include #include +#include #include #include @@ -30,15 +31,25 @@ struct folio *hugetlb_cma_alloc_frozen_folio(int order, gfp_t gfp_mask, int node; struct folio *folio; struct page *page = NULL; + const nodemask_t *nmask; + unsigned int cpuset_mems_cookie; if (!hugetlb_cma_size) return NULL; - if (hugetlb_cma[nid]) +retry_cpuset: + if (!nodemask) { + cpuset_mems_cookie = read_mems_allowed_begin(); + nmask = &cpuset_current_mems_allowed; + } else { + nmask = nodemask; + } + + if (hugetlb_cma[nid] && node_isset(nid, *nmask)) page = cma_alloc_frozen_compound(hugetlb_cma[nid], order); if (!page && !(gfp_mask & __GFP_THISNODE)) { - for_each_node_mask(node, *nodemask) { + for_each_node_mask(node, *nmask) { if (node == nid || !hugetlb_cma[node]) continue; @@ -48,8 +59,12 @@ struct folio *hugetlb_cma_alloc_frozen_folio(int order, gfp_t gfp_mask, } } - if (!page) + if (!page) { + if (!nodemask && + unlikely(read_mems_allowed_retry(cpuset_mems_cookie))) + goto retry_cpuset; return NULL; + } folio = page_folio(page); folio_set_hugetlb_cma(folio); -- 2.55.0