Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2026-93237LoongArch: Add DIRECT_MAP_PHYSMEM_END definition

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

Timeline

  1. ID reserved

    By Linux

  2. · 7 days later

    Published

  3. · 25 days later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2026-93237, by who scored it
Scored byCVSSScoreVector
LinuxCNA (assigner)3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
NVDNVD · Received3.1High7.8CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS (exploitation in 30 days)
0.17% · top 93% of all CVEs (14 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.

Affected products

  • Linux · Linux

    • affected 7b09f5af01ede480cbe7abcb281cf17550a46ff5 – < ab275a23b4d9f04ca6c2f5f6a3246194e045a761
    • affected 7b09f5af01ede480cbe7abcb281cf17550a46ff5 – < 55e18311c705cceef6c34d522ea387b1f0069bab
    • affected 7b09f5af01ede480cbe7abcb281cf17550a46ff5 – < 2677f97a67fdbc62a82ce1faa67791f54451d36f
  • Linux · Linux

    • affected 6.2
    • unaffected < 6.2
    • unaffected 6.18.51 – ≤ 6.18.*
    • unaffected 7.2.5 – ≤ 7.2.*
    • unaffected 7.3 – ≤ *

References

References3

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-93237 badge
[![CVE-2026-93237](https://cveledger.app/badge/CVE-2026-93237.svg)](https://cveledger.app/cve/CVE-2026-93237)

Record last updated .