Re: [PATCH] smaps: Fix crash in smaps_hugetlb_range for non-present hugetlb entries

[David Hildenbrand <david@redhat.com>]

On 23.04.25 03:03, Ming Wang wrote:
> When reading /proc/pid/smaps for a process that has mapped a hugetlbfs
> file with MAP_PRIVATE, the kernel might crash inside pfn_swap_entry_to_page.
> This occurs on LoongArch under specific conditions.
> 
> The root cause involves several steps:
> 1. When the hugetlbfs file is mapped (MAP_PRIVATE), the initial PMD
>     (or relevant level) entry is often populated by the kernel during mmap()
>     with a non-present entry pointing to the architecture's invalid_pte_table
>     On the affected LoongArch system, this address was observed to
>     be 0x90000000031e4000.
> 2. The smaps walker (walk_hugetlb_range -> smaps_hugetlb_range) reads
>     this entry.
> 3. The generic is_swap_pte() macro checks `!pte_present() && !pte_none()`.
>     The entry (invalid_pte_table address) is not present. Crucially,
>     the generic pte_none() check (`!(pte_val(pte) & ~_PAGE_GLOBAL)`)
>     returns false because the invalid_pte_table address is non-zero.
>     Therefore, is_swap_pte() incorrectly returns true.
> 4. The code enters the `else if (is_swap_pte(...))` block.
> 5. Inside this block, it checks `is_pfn_swap_entry()`. Due to a bit
>     pattern coincidence in the invalid_pte_table address on LoongArch,
>     the embedded generic `is_migration_entry()` check happens to return
>     true (misinterpreting parts of the address as a migration type).
> 6. This leads to a call to pfn_swap_entry_to_page() with the bogus
>     swap entry derived from the invalid table address.
> 7. pfn_swap_entry_to_page() extracts a meaningless PFN, finds an
>     unrelated struct page, checks its lock status (unlocked), and hits
>     the `BUG_ON(is_migration_entry(entry) && !PageLocked(p))` assertion.
> 
> The original code's intent in the `else if` block seems aimed at handling
> potential migration entries, as indicated by the inner `is_pfn_swap_entry()`
> check. The issue arises because the outer `is_swap_pte()` check incorrectly
> includes the invalid table pointer case on LoongArch.

This has a big loongarch smell to it.

If we end up passing !pte_present() && !pte_none(), then loongarch must 
be fixed to filter out these weird non-present entries.

is_swap_pte() must not succeed on something that is not an actual swap pte.

-- 
Cheers,

David / dhildenb