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

["David Hildenbrand (Arm)" <david@kernel.org>]

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.

-- 
Cheers,

David