CVE-2026-93237

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 CPUs 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/

Affected Software

References

• https://git.kernel.org/stable/c/2677f97a67fdbc62a82ce1faa67791f54451d36f
• https://git.kernel.org/stable/c/55e18311c705cceef6c34d522ea387b1f0069bab
• https://git.kernel.org/stable/c/ab275a23b4d9f04ca6c2f5f6a3246194e045a761