From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (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 F3A2726159E for ; Fri, 26 Jun 2026 03:40:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782445232; cv=none; b=KUNP6nvk8cuX0XfPslomS5/EiruyQqAL0tudbJWyMLYPY0FZoK3iaoPJ0SKZBfgmHzYpcAA0LZ0Q4Cb0U7Cy8AoGdKQ5RFHFPbeSSSyNtFYuP1r9Z1DEWmdGC6quavMa6ngZ/kEDqukBvepdJ5rw4F02ZT387+Ms71wY53rAQBI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782445232; c=relaxed/simple; bh=eahrMRZWrZeJQojgi2LFzBSzlad5LrnQZOpjXQUN7GM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cpEyKTe1KZoTKWX94x/J/4sNPyzsQyZKmHkLZNTkEOLwQ8S14cctfcsv6cm2cqS7NwK2ovhjN5c+xbTL5iWq6IA8zWLJzuAIKcTF66bsk1HgJdPsjqurtb/Aq/xPHTA2T6CxGPMDP6u2qiRFVBf45/zn6I70dFGHJwMYO0OfSko= 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=reozai8T; arc=none smtp.client-ip=91.218.175.172 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="reozai8T" Message-ID: <28f75d0d-de54-43a1-b46a-fe3dd1188929@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782445228; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QuVdpRIguPMFSlXQhOOtEgFq7gSJAyQxVrZOCwx3KkM=; b=reozai8TTI24Te6z59/Idhy/4ExwpoKf76qZ/QygeLqLnuQaqt+53ywcl6JtzSMN8/yEoT hNSB+NcGUreDFseQjyBqyhDgwgmftLUFFTH0OhkVJxOrWUydco42qggU6eqoewmaEhomQR lfwAoz3mnILobNZHkWC1MDxCAkqScBY= Date: Fri, 26 Jun 2026 11:40:03 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 5/5] mm/mprotect: use huge_ptep_get() for hugetlb To: Dev Jain Cc: riel@surriel.com, vbabka@kernel.org, harry@kernel.org, jannh@google.com, lance.yang@linux.dev, kas@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rcampbell@nvidia.com, apopple@nvidia.com, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, mel@csn.ul.ie, nao.horiguchi@gmail.com, ak@linux.intel.com, j-nomura@ce.jp.nec.com, pfalcato@suse.de, dave.hansen@intel.com, tglx@kernel.org, jpoimboe@kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com, osalvador@suse.de, akpm@linux-foundation.org, ljs@kernel.org, david@kernel.org, liam@infradead.org References: <20260625112955.3254283-1-dev.jain@arm.com> <20260625112955.3254283-6-dev.jain@arm.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20260625112955.3254283-6-dev.jain@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2026/6/25 19:29, Dev Jain wrote: > prot_none_hugetlb_entry() is the hugetlb callback for the early > mprotect(PROT_NONE) PFN permission walk on x86. > > The callback passes the decoded PFN to pfn_modify_allowed(). For a > hugetlb callback, the pte pointer refers to a hugetlb entry. On > architectures where hugetlb entries need huge_ptep_get(), reading that > entry with ptep_get() can make the permission check use the wrong PFN. > > Use huge_ptep_get() before decoding the hugetlb PFN. > > Currently there is no path which can trigger a bug: huge_ptep_get() is a > simple ptep_get() for x86, and the prot_none walk occurs only for x86. > But use the correct helper anyways. > > Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings") > Signed-off-by: Dev Jain > --- > mm/mprotect.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/mm/mprotect.c b/mm/mprotect.c > index 9cbf932b028cf..23779632d18bf 100644 > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr, > 0 : -EACCES; > } > > +#ifdef CONFIG_HUGETLB_PAGE > static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask, > unsigned long addr, unsigned long next, > struct mm_walk *walk) > { > - return pfn_modify_allowed(pte_pfn(ptep_get(pte)), > + pte_t entry = huge_ptep_get(walk->mm, addr, pte); > + > + return pfn_modify_allowed(pte_pfn(entry), > *(pgprot_t *)(walk->private)) ? > 0 : -EACCES; > } > +#else > +#define prot_none_hugetlb_entry NULL This is very strange, because we defined a stub as NULL for a helper function. How about  the following diff? diff --git a/mm/mprotect.c b/mm/mprotect.c index 9cbf932b028c..4d8c1551fbce 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -716,7 +716,9 @@ static int prot_none_test(unsigned long addr, unsigned long next,  static const struct mm_walk_ops prot_none_walk_ops = {         .pte_entry              = prot_none_pte_entry, +#ifdef CONFIG_HUGETLB_PAGE         .hugetlb_entry          = prot_none_hugetlb_entry, +#endif         .test_walk              = prot_none_test,         .walk_lock              = PGWALK_WRLOCK,  }; Thanks, Muchun > +#endif > > static int prot_none_test(unsigned long addr, unsigned long next, > struct mm_walk *walk)