CVE-2026-93237: LoongArch: Add DIRECT_MAP_PHYSMEM_END definition
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Add DIRECTMAPPHYSMEMEND definition
getfreememregion() and mhpgetpluggablerange() bound their search to DIRECTMAPPHYSMEMEND. LoongArch does not define it, so the fallback in include/linux/mm.h applies: under CONFIGSPARSEMEMVMEMMAP it is (1ULL << MAXPHYSMEMBITS) - 1, a compile-time constant that does not adapt to the CPU's physical address space bits (cpupabits, probed from CPUCFG1).
The vmemmap window only covers physical space below 2^(cpupabits+1) (i.e. VMEMMAPSIZE), so on CPUs with fewer physical address bits than MAXPHYSMEMBITS the fallback allows getfreememregion() to return a ZONEDEVICE region outside the vmemmap window; vmemmappopulate() 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 memmapinitzonedevice() 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 cpupabits (e.g. the Loongson-2K series) are still affected.
Define DIRECTMAPPHYSMEMEND as the vmemmap-covered physical range, (1ULL << (cpupabits + 1)) - 1, capped at (1ULL << MAXPHYSMEMBITS) - 1 under CONFIGSPARSEMEM, similar to the commit f3336b48cf9d ("riscv: mm: Define DIRECTMAPPHYSMEMEND").
[1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range, adapting it to the CPU's probed physical address-space bits (cpu_pabits).
Linux kernel on LoongArch DIRECT_MAP_PHYSMEM_END = (1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue applies to LoongArch Linux systems using CONFIG_SPARSEMEM_VMEMMAP where the CPU physical-address width, cpu_pabits, is smaller than MAX_PHYSMEM_BITS. The fallback memory limit can then exceed the vmemmap window supported by that CPU.
What operation reaches the vulnerable path?
The affected searches are get_free_mem_region() and mhp_get_pluggable_range(). A search can select a ZONE_DEVICE region outside the vmemmap window, including the top-of-address-space region described in the report.
What can happen if an out-of-range region is selected?
vmemmap_populate() can wrap the memmap range and map it into low memory, silently corrupting page tables. The report also describes a crash in memmap_init_zone_device() with amdkfd on Loongson-3C6000 in 6.16.
Does the report identify an attacker access level or remote exploitation path?
No. The provided information describes a kernel memory-management boundary error and its effects, but does not specify an attacker model, required privileges, or a remote attack path.