CVE-2026-93237 in Linux
Summary
by MITRE • 09/24/2026
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/[email protected]/
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel vulnerability identified in the LoongArch architecture stems from a critical misconfiguration of physical memory mapping boundaries, specifically involving the DIRECT_MAP_PHYSMEM_END definition. This issue affects functions such as get_free_mem_region() and mhp_get_pluggable_range(), which rely on this boundary to restrict their search for available memory regions. In architectures where this constant is not explicitly defined, the kernel falls back to a generic implementation in include/linux/mm.h that uses (1ULL << MAX_PHYSMEM_BITS) - 1 as the upper limit under CONFIG_SPARSEMEM_VMEMMAP configurations. This fallback value is a compile-time constant and fails to adapt dynamically to the actual physical address space bits of the CPU, known as cpu_pabits, which are probed from CPUCFG1 during runtime initialization. Consequently, on LoongArch systems with fewer physical address bits than MAX_PHYSMEM_BITS, the kernel may allocate memory regions that lie outside the valid vmemmap window, leading to severe system instability and potential data corruption.
The technical flaw manifests when get_free_mem_region() returns a ZONE_DEVICE region that falls outside the range covered by the vmemmap structure. The vmemmap is responsible for managing page metadata for physical memory, and it only covers physical space below 2^(cpu_pabits+1), defined as VMEMMAP_SIZE. When an out-of-bounds address is passed to vmemmap_populate(), the function wraps the memmap range around and maps it into low memory. This action silently corrupts page tables because the mapping does not correspond to valid physical memory structures, violating kernel memory management integrity. Such corruption can lead to unpredictable behavior, including silent data loss or system hangs, as the kernel attempts to access invalid or unmapped pages through corrupted metadata structures.
The operational impact of this vulnerability includes both stability issues and potential security implications due to memory corruption. In specific cases, such as on Loongson-3C6000 processors running amdkfd in Linux version 6.16, the incorrect search range caused memmap_init_zone_device() to crash, disrupting device functionality and system reliability. Although subsequent commits like 2969b42c8f99 aligned vmemmap to maximal folio size for current Loongson-3C6000 configurations, CPUs with smaller cpu_pabits values, such as those in the Loongson-2K series, remain vulnerable. These systems continue to experience crashes or undefined behavior because their physical address space limits are not properly respected by the memory allocation routines, leading to failed device initialization and potential denial of service conditions for workloads relying on these hardware features.
From a security perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write, as it involves writing or mapping data into invalid memory regions due to incorrect boundary checks. It also relates to CWE-20: Improper Input Validation, since the kernel fails to validate that allocated physical addresses fall within the supported hardware address space before proceeding with page table population. In terms of MITRE ATT&CK framework behaviors, this could be leveraged in an exploit chain involving memory corruption techniques (T1564) or privilege escalation if an attacker can trigger specific allocation patterns that result in controlled overwrites of kernel structures via corrupted vmemmap entries. However, the primary impact remains system instability rather than direct exploitation for code execution without additional context-specific vulnerabilities.
To mitigate this vulnerability, it is essential to define DIRECT_MAP_PHYSMEM_END as the physical range covered by vmemmap, calculated as (1ULL << (cpu_pabits + 1)) - 1, while ensuring it does not exceed (1ULL << MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM. This approach mirrors fixes applied in other architectures like RISC-V and ensures that memory allocation routines respect the actual hardware capabilities of each CPU variant. Developers should verify that all LoongArch variants properly probe cpu_pabits early during boot and apply this limit consistently across all memory management functions. Additionally, adding runtime checks to validate allocated addresses against vmemmap boundaries before calling vmemmap_populate() can provide an extra layer of defense against potential corruption scenarios. Regular updates to the kernel source code incorporating these architectural-specific adjustments are necessary to maintain system integrity and prevent crashes on affected hardware platforms.