Re: [PATCH 7/9] mm/kasan: use hw_pte_t for the early shadow PTE table

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Invalid non-present page table entry conversion in ptdump callbacks.
--

--- Patch [7]: [PATCH 7/9] mm/kasan: use hw_pte_t for the early shadow PTE table ---
commit 3ee38376d3d7f9e85666863e4080641fcf9b048b
Author: Muhammad Usama Anjum <usama.anjum@arm.com>

mm/kasan: use hw_pte_t for the early shadow PTE table

kasan_early_shadow_pte is a complete PTE table rather than a standalone
PTE value. Declare and define its elements as hw_pte_t so the object uses
the PTE table storage type.

[ ... ]

> diff --git a/mm/ptdump.c b/mm/ptdump.c
> index 376880071ca2a..8f19f20be3c44 100644
> --- a/mm/ptdump.c
> +++ b/mm/ptdump.c
> @@ -19,7 +19,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk,
>  {
>  	struct ptdump_state *st = walk->private;
>  
> -	st->note_page_pte(st, addr, kasan_early_shadow_pte[0]);
> +	st->note_page_pte(st, addr, ptep_get(kasan_early_shadow_pte));

[Severity: High]
This isn't a bug introduced by this patch, but since we are modifying the KASAN
shadow table handling in ptdump, are the page extraction checks that lead here
safe for non-present entries?

In mm/ptdump.c, callbacks like ptdump_pmd_entry() and ptdump_pud_entry()
unconditionally call pmd_page() and pud_page() before checking if the entry
is present:

mm/ptdump.c:ptdump_pmd_entry() {
    ...
	pmd_t val = pmdp_get(pmd);

#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
	if (pmd_page(val) == virt_to_page(lm_alias(kasan_early_shadow_pte)))
		return note_kasan_page_table(walk, addr);
#endif
    ...
}

User page tables can contain non-present swap or migration entries at the PMD
level. If pmd_page() (and equivalents like pud_page(), p4d_page(), pgd_page())
extracts a bogus PFN from a non-present entry, could this lead to an
out-of-bounds array access and a NULL pointer dereference in the sparsemem
arrays when pfn_to_page() is evaluated?

Since ptdump can be invoked on user page tables via debugfs by users with read
access, could this trigger a kernel panic? Should these callbacks verify the
entry is present before calling the page conversion functions?

>  
>  	walk->action = ACTION_CONTINUE;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806083926.1807279-1-usama.anjum@arm.com?part=7