CVE-2026-93237 LoongArch: Add DIRECT_MAP_PHYSMEM_END definition

Q: Is CVE-2026-93237 being exploited?

There is no known exploitation of CVE-2026-93237 in the wild and no public exploit code.

High 7.8 Published 24 Sep 2026 Updated 19 Oct 2026

Missing memory boundary definition in LoongArch Linux kernel allows page table corruption and crashes on specific CPUs.

Exploited in the wild: Not known
Login needed: Any signed-in user
Attackable: Local or same network only
Victim action needed: Not needed
Fix: Available

What is CVE-2026-93237?

CVE-2026-93237 is a high-severity memory corruption vulnerability in Linux, published on 24 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official 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/[email protected]/

Which versions are affected by CVE-2026-93237?

How do I fix CVE-2026-93237?

Apply the vendor's patch.

Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.

Is CVE-2026-93237 being exploited?