Re: [PATCH v3 0/6] Fix incorrect access of hugetlb pte entries

[Dev Jain]

On 22/07/26 2:06 am, Andrew Morton wrote:
> On Tue, 21 Jul 2026 18:18:38 +0100 Will Deacon <will@xxxxxxxxxx> wrote:
> 
>> On Fri, 03 Jul 2026 11:41:53 +0000, Dev Jain wrote:
>>> There are various places which use ptep_get() to get the pte entry
>>> corresponding to a hugetlb folio. Some arches (like s390) have special
>>> handling to compute the pteval, so they provide huge_ptep_get(). Use this
>>> helper consistently.
>>>
>>> Additionally, some code paths may provide huge_ptep_get with an unaligned
>>> address. This is a problem on arm64 (I checked other arches and it looks
>>> fine for them), which is fixed in patch 1. The fix is made to be
>>> to huge_ptep_get() - that is wider churn and we can do that later.
>>>
>>> [...]
>>
>> Applied first patch to arm64 (for-next/fixes), thanks!
>>
>> [1/6] arm64: make huge_ptep_get handled unaligned addresses
>>       https://git.kernel.org/arm64/c/9175a8c7cfe88
>>
>> I'm hoping Andrew can drop this from the mm tree to avoid a duplicate,
>> but I didn't hear back yet and I'd like to land the fix.
> 
> I can redo Dev's series to omit [1/6].  The patches apply that way, but
> there might be build-time or runtime issues running the other patches
> without [1/6] present, haven't looked.
> 
> Also, review indicates that the changelog requires updating
> (https://lore.kernel.org/all/2b9d60a2-8698-46b0-80ae-b8747a66a85b@xxxxxxxxxx/)
> and I believe that Dev plans to do that.

Oh I was banking on you to do that : )

@Will if you could edit the commit message with the following userspace visible
effect:

"On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect
excess a/d bit state, meaning extra work for the kernel. Even worse, we may iterate
beyond the PTE table and dereference a garbage ptep pointer to access physical
memory we don't own. Since the ptep pointer is a linear map address, we may run off
the end of the linear map, dereference a VA not mapped into the kernel pgtables and
cause kernel panic."

> 
> IOW, it would be better to carry this in mm.git with your ack.
> 
> Do you plan to upstream this in 7.2-rcX?  If so then I can hang onto
> this patch until it appears in mainline.  Or something.