{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.6-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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 \u003c\u003c 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 \u003c\u003c (cpu_pabits + 1)) - 1, capped at (1ULL \u003c\u003c 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/",
  "id": "DEBIAN-CVE-2026-93237",
  "modified": "2026-09-26T08:47:37.519039431Z",
  "published": "2026-09-24T16:17:19.447Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-93237"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-93237"
  ]
}