In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Add DIRECT MAP PHYSMEM END definition

get free mem region() and mhp get pluggable range() bound their search to DIRECT MAP PHYSMEM END. LoongArch does not define it, so the fallback in include/linux/mm.h applies: under CONFIG SPARSEMEM VMEMMAP it is (1ULL << MAX PHYSMEM BITS) - 1, a compile-time constant that does not adapt to the CPU's physical address space bits (cpu pabits, probed from CPUCFG1).

The vmemmap window only covers physical space below 2^(cpu pabits+1) (i.e. VMEMMAP SIZE), so on CPUs with fewer physical address bits than MAX PHYSMEM BITS the fallback allows get free mem region() to return a ZONE DEVICE region outside the vmemmap window; vmemmap populate() then wraps the memmap range around and maps it into low memory, silently corrupting the page tables. The same search also picked the top-of- address-space region that crashed memmap init zone device() with amdkfd on Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio size") keeps that region in bounds on current Loongson-3C6000 configs, but CPUs with smaller cpu pabits (e.g. the Loongson-2K series) are still affected.

Define DIRECT MAP PHYSMEM END as the vmemmap-covered physical range, (1ULL << (cpu pabits + 1)) - 1, capped at (1ULL << MAX PHYSMEM BITS) - 1 under CONFIG SPARSEMEM, similar to the commit f3336b48cf9d ("riscv: mm: Define DIRECT MAP PHYSMEM END").

[1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/