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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux