CVE-2026-93237

Status: UPDATED  |  Advisory ID: CVE-2026-93237

Key Details

Affected Products, Subsystems & Sectors

What to Know

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]/ (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References