Description

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/

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-24T16:17:19.447Z",
  "pubdate": "2026-09-24T16:17:19.447Z",
  "executiveSummary": "The vulnerability is a memory management flaw in the Linux kernel on the LoongArch architecture, specifically involving improper bounds checking during the allocation of pluggable memory regions.\nThe root cause is the absence of a platform-specific definition for DIRECT_MAP_PHYSMEM_END, which forces the kernel to rely on a generic fallback constant that exceeds the physical address space supported by certain LoongArch CPUs (e.g., Loongson-2K series).\nThis mismatch allows functions like get_free_mem_region() to return addresses residing outside the valid vmemmap window.\nSuccessful exploitation results in memory corruption, as vmemmap_populate() wraps the range around and maps it into lower memory, potentially leading to page table corruption or system crashes.\nWhile this is a memory safety vulnerability, it generally requires an environment utilizing ZONE_DEVICE or similar pluggable memory features to be triggered.\nThe flaw impacts system stability and data integrity, with the potential for local denial-of-service (DoS) or arbitrary memory write primitives under specific conditions.",
  "technicalDetails": "The Linux kernel's memory management subsystem uses get_free_mem_region() and mhp_get_pluggable_range() to identify address ranges for ZONE_DEVICE. These functions rely on the constant DIRECT_MAP_PHYSMEM_END to bound their search. On LoongArch, the lack of this explicit definition triggers a fallback in include/linux/mm.h, setting the limit to (1ULL << MAX_PHYSMEM_BITS) - 1.\nThis hardcoded compile-time constant fails to account for the actual physical address space bits (cpu_pabits) of the specific LoongArch CPU, which are probed at runtime via CPUCFG1. Because the vmemmap window is restricted to the physical space below 2^(cpu_pabits+1) (VMEMMAP_SIZE), CPUs with fewer physical address bits than MAX_PHYSMEM_BITS are vulnerable to out-of-bounds allocations.\nWhen get_free_mem_region() returns an address beyond the valid range, vmemmap_populate() attempts to map the memmap for this region. Due to the address mismatch, the range is wrapped around and mapped into low memory addresses. This process silently overwrites existing page table entries or critical kernel memory structures.\nThe attack flow involves the kernel attempting to initialize a device memory range that appears valid to the generic mm subsystem but is physically invalid for the specific hardware configuration. When memmap_init_zone_device() operates on this out-of-bounds range, it triggers the corruption. This scenario was notably observed in the context of amdkfd on Loongson-3C6000 hardware, where top-of-address-space regions crashed the kernel initialization process.\nThe vulnerability is inherent to the memory initialization logic on LoongArch kernels. It does not require network exposure or specific authentication; rather, it is a local memory management defect triggered during the boot or hot-plug process when the kernel allocates memory for devices. The post-exploitation impact includes kernel panics, system instability, or the potential for an attacker to influence memory mapping logic to facilitate further kernel-level memory corruption."
}