linux-kernel - Re: [PATCH] smaps: Fix crash in smaps_hugetlb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b64aea02-cc44-433a-8214-854feda2c06d@redhat.com>
Date: Wed, 23 Apr 2025 09:07:36 +0200
From: David Hildenbrand <david@...hat.com>
To: Ming Wang <wangming01@...ngson.cn>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Matthew Wilcox <willy@...radead.org>, Oscar Salvador <osalvador@...e.de>,
 Andrii Nakryiko <andrii@...nel.org>, Ryan Roberts <ryan.roberts@....com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Naoya Horiguchi <nao.horiguchi@...il.com>, Michal Hocko <mhocko@...e.cz>,
 David Rientjes <rientjes@...gle.com>, Joern Engel <joern@...fs.org>,
 Hugh Dickins <hughd@...gle.com>, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org
Cc: Huacai Chen <chenhuacai@...nel.org>, lixuefeng@...ngson.cn,
 Hongchen Zhang <zhanghongchen@...ngson.cn>
Subject: Re: [PATCH] smaps: Fix crash in smaps_hugetlb_range for non-present
 hugetlb entries

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