Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses

[Will Deacon <will@kernel.org>]

On Mon, Jul 06, 2026 at 04:04:40PM +0200, David Hildenbrand (Arm) wrote:
> On 7/6/26 12:54, Dev Jain wrote:
> > 
> > 
> > On 06/07/26 4:22 pm, Dev Jain wrote:
> >>
> >>
> >> On 06/07/26 2:15 pm, David Hildenbrand (Arm) wrote:
> >>>
> >>> Even worse, right? We could walk 128 entries, when we really should just walk 16
> >>> (IIRC) entries, possibly reading garbage or even worse, into a memory hole at
> >>> the end of memory?
> >>
> >> Hmm I was thinking that the checks pte_dirty() and pte_young() wouldn't care whether
> >> the pte is garbage. But, we could actually dereference a ptep pointer not having
> >> backing memory at all.
> >>
> >> Does the following sound good?
> >>
> >> "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."
> >>
> >> Although I checked on arm64, there is no case in which there is a hole after the
> >> linear map, but still that assumption shouldn't be made.
> > 
> > Oh but we could access a linear map address which corresponds to a DRAM hole, meaning
> > there is no entry in the kernel pgtable.
> 
> Yes, exactly. With debug-pagealloc and things like that we might have many holes
> in the direct map.

I think this one patch should go in as a fix.

Andrew, do you mind if I pick it via arm64? If you'd rather manage the
whole lot, please can you send just this one as a fix for this cycle?

Thanks,

Will