Look up another CVE · open CVE-2026-93237 in the interactive tracker
CVE-2026-93237
LoongArch: Add DIRECT_MAP_PHYSMEM_END definition
Published 2026-09-24 (24 days ago) by the Linux kernel CNA. Subsystem arch/loongarch. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-93237 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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/
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/loongarch/include/asm/pgtable.h
- What this is
- LOONGARCHMAINTAINERS section matched on arch/loongarch/ · loongarch@lists.linux.dev · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-09-24 (24 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/loongarch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.2 | 6.18.51 | ab275a23b4d9 |
| 6.2 | 7.2.5 | 55e18311c705 |
| 6.2 | 7.3 | 2677f97a67fd |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The missing DIRECT_MAP_PHYSMEM_END is consumed by gfr_start() inside get_free_mem_region() when kgd2kfd_init_zone_device() calls devm_request_free_mem_region(&iomem_resource) from amdgpu device init (HSA_AMD depends on LOONGARCH && 64BIT); that is local PCI-probe HMM setup, not a remote protocol message.
- AC:LAttack complexity, low
- With GFR_DESCENDING, gfr_start() always starts at min(iomem_resource.end, the mm.h fallback (1ULL<<MAX_PHYSMEM_BITS)-1) minus size, so on a CPU with cpu_pabits+1 below 48 the first ZONE_DEVICE slot is above VMEMMAP_SIZE and vmemmap_populate() wraps with no race or victim-owned device fault.
- PR:LPrivileges required, low
- amdgpu PCI probe runs kgd2kfd_init_zone_device()→devm_memremap_pages() with no capable() check from userspace; after that wrap the unprivileged local account on a typical ROCm/desktop LoongArch host (render group, /dev/kfd with kfd_open() likewise ungated) shares the corrupted init_mm without init-namespace root.
- UI:NUser interaction, none
- amdgpu_device init itself calls kgd2kfd_init_zone_device() and then pagemap_range()→add_pages()→vmemmap_populate() on PCI bind; no victim must mount media, open a file, or click, and any NOUVEAU_SVM_BIND the attacker issues is on their own DRM fd.
- S:UScope, unchanged
- LoongArch vmemmap_populate() (vmemmap_set_pmd/vmemmap_populate_hugepages) writes PTEs via pgd_offset_k() into init_mm for the wrapped pfn_to_page() VA, which is host kernel MM corruption, not a KVM guest-to-host escape or IOMMU/DMA bypass.
- C:HConfidentiality impact, high
- __populate_section_memmap() sets start to (unsigned long)pfn_to_page() of the out-of-window ZONE_DEVICE PFN, so vmemmap_populate() maps struct-page backing over low kernel VAs; memmap_init_zone_device() then stores page->pgmap and flags through that alias, disclosing kernel pointers and data those VAs previously mapped.
- I:HIntegrity impact, high
- vmemmap_set_pmd() installs PAGE_KERNEL PMDs at the wrapped address and memmap_init_zone_device() writes struct-page fields through pfn_to_page() into that alias, an unconstrained kernel page-table and metadata write rather than a bounded data tweak.
- A:HAvailability impact, high
- The same top-of-address-space region already crashed memmap_init_zone_device() with amdkfd on Loongson-3C6000, and on smaller cpu_pabits the wrap leaves init_mm PTEs pointing at the wrong physical pages so later pfn_to_page() walks oops or panic the host.