Re: [PATCH 1/2] sh: mm: replace the page size bits in pte_mkhuge()

[Mike Rapoport]

On Sat, Sep 26, 2026 at 08:39:03PM +0200, Karl Mehltretter wrote:
> pte_mkhuge() ORs _PAGE_SZHUGE into a PTE that already carries the base
> page size from _PAGE_FLAGS_HARD, which every PAGE_* protection
> includes. The PTEL size field is an encoding, not a set of flags: on
> SH-4 with 4 KiB pages and 64 KiB huge pages, _PAGE_SZ0 | _PAGE_SZ1
> selects a 1 MiB page. Every hugetlb mapping is therefore loaded into
> the UTLB as a 1 MiB page whose physical base is the huge page's address
> rounded down to 1 MiB, so user accesses land in unrelated kernel
> memory.
> 
> In a QEMU r2d guest, after touching a MAP_HUGETLB mapping at
> 0x30000000, QEMU's "info tlb" shows
> 
>   vpn=c0000 ppn=32e00 sz=3 size=1048576
> 
> and writing the two huge pages overwrites kernel data, for example
> page tables ("bad pgd 5a5a5a5a" on munmap) or a struct file:
> 
>   Fault in unaligned fixup: 0000 [#1]
>   PC is at file_tty_write.isra.0+0x24/0x220
>   R1  : 5a5a5a5a
> 
> The SH-X2 extended size field has the same problem: a 4 KiB base page
> (ESZ0) combined with 64 KiB huge pages (ESZ2) encodes 256 KiB. Only the
> configurations whose huge size encoding happens to contain the base
> encoding, such as 1 MiB over 4 KiB on SH-4, have worked.
> 
> Clear the size field before setting the huge page size. All hugetlb
> PTE constructors, including huge_pte_modify() on mprotect() and the
> fork/COW paths, go through arch_make_huge_pte() and so pte_mkhuge().
> With this change the same entry is loaded as
> 
>   vpn=c0000 ppn=32e00 sz=2 size=65536
> 
> and the mappings read back correctly after mprotect() and fork()/COW.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

This implies nobody ever used hugetlb on sh-4, doesn't it?

> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@xxxxxxxxx>
> ---
>  arch/sh/include/asm/pgtable_32.h | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

-- 
Sincerely yours,
Mike.