From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-115.mta0.migadu.com [91.218.175.115]) (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 5DD9725771 for ; Wed, 12 Aug 2026 02:03:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.115 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786500196; cv=none; b=GeIkUIQKEgH/HGZnGDHIZdC3rZwOww8Vcs7SJNRQNsK6chcSu892uGSEZjUa5AkKIxCx7svMl9qUaLxsQKO3AmrmA/wG5jiH0xBxfLeaF2HqjgAcgw9Doxgjv6gHRJxPnLzoGwLO68hhNWxYsXF1iwEmUbKa1BYi1inxptBbkbE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786500196; c=relaxed/simple; bh=WXz8poCGQHTsMTeMQdLmtjs1wHxY8Y3zIy5+1lnV7d0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=UL+3/ZTJpTiiQi9nn6nv56zDDZb9F2IJNiUYMeXzB8Oseudy+pUGHEwPYNduLSiMq7UaO9ycQ22pcyWHWmirtsCqCFihg3ZKdY2864gFavfR0yyrr1AZUe2WL/1PCTpwy5VP7e6ZAL2pH3iD4HWRTOGunWeBIipDfXvpCHA66Xo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=EEXudKNo; arc=none smtp.client-ip=91.218.175.115 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="EEXudKNo" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=WXz8poCGQHTsMTeMQdLmtjs1wHxY8Y3zIy5+1lnV7d0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786500192; v=1; x=1787104992; b=EEXudKNoiCplueNcx5lw4SaxIp/WMxrSDLYcPq4HZzuDAT2Fc/utR+JD+COg0s7FAhdtWyAH sJcgJ54ahTx1d76Uyj4VtbO/ej7P4fwxGXOJZDNtRK4ThbwQkYsQkdAp79pV3BzqCQxUZuuYfb9 I4dQdlqhanY5Gt6l7lkraFF8= X-Envelope-To: linux-kernel@vger.kernel.org Received: from smtpclient.apple (183.241.155.34) by mta11.migadu.com with ESMTPS id 51bb0a907f71a2d6; Wed, 12 Aug 2026 02:03:12 +0000 X-Migadu-Scanner: mta11.migadu.com Authentication-Results: mta11.migadu.com; none Content-Type: text/plain; charset=us-ascii Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH v7] mm/hugetlb_cma: Fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio From: Muchun Song In-Reply-To: <20260811185531.b8e3fb91c51713b2f29bc1f0@linux-foundation.org> Date: Wed, 12 Aug 2026 10:02:45 +0800 Cc: Sourav Panda , osalvador@suse.de, 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, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260811052909.475635-1-souravpanda@google.com> <20260811185531.b8e3fb91c51713b2f29bc1f0@linux-foundation.org> To: Andrew Morton X-Mailer: Apple Mail (2.3864.600.51.1.1) > On Aug 12, 2026, at 09:55, Andrew Morton = wrote: >=20 > On Tue, 11 Aug 2026 05:29:09 +0000 Sourav Panda = wrote: >=20 >> 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(). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> =46rom 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. >=20 > Thanks. Sashio might have found another thing with = MPOL_PREFERRED_MANY > and CMA: >=20 > = https://sashiko.dev/#/patchset/20260811052909.475635-1-souravpanda@google.= com Yes, we already noticed that issue in the previous version. However, I = believe this should be addressed as a separate patch within = alloc_contig_frozen_pages itself, rather than in the HugeTLB code, since this is a low-level = memory allocation interface that should not be tied solely to HugeTLB usage. Muchun, Thanks. >=20 >=20 >=20 > We're days away from 7.2 and I do dislike sending hotfixes upstream at > such a late stage. I expect I'll upstream this and a few other > hotfixes after 7.2 is released. It'll all end up in the same place. >=20 > I would still upstream hotfixes which address added-in-this-cycle = bugs, > but there aren't any of those at present.