{"api_version":"1","generated_at":"2026-10-01T11:59:20+00:00","cve":"CVE-2026-93237","urls":{"html":"https://cve.report/CVE-2026-93237","api":"https://cve.report/api/cve/CVE-2026-93237.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-93237","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-93237"},"summary":{"title":"LoongArch: Add DIRECT_MAP_PHYSMEM_END definition","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add DIRECT_MAP_PHYSMEM_END definition\n\nget_free_mem_region() and mhp_get_pluggable_range() bound their search\nto DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback\nin include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is\n(1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not\nadapt to the CPU's physical address space bits (cpu_pabits, probed from\nCPUCFG1).\n\nThe vmemmap window only covers physical space below 2^(cpu_pabits+1)\n(i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than\nMAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return\na ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then\nwraps the memmap range around and maps it into low memory, silently\ncorrupting the page tables. The same search also picked the top-of-\naddress-space region that crashed memmap_init_zone_device() with amdkfd\non Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 (\"LoongArch/mm:\nalign vmemmap to maximal folio size\") keeps that region in bounds on\ncurrent Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g.\nthe Loongson-2K series) are still affected.\n\nDefine DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range,\n(1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1\nunder CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d (\"riscv: mm:\nDefine DIRECT_MAP_PHYSMEM_END\").\n\n[1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-24 16:17:19","updated_at":"2026-09-25 13:17:17"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/ab275a23b4d9f04ca6c2f5f6a3246194e045a761","name":"https://git.kernel.org/stable/c/ab275a23b4d9f04ca6c2f5f6a3246194e045a761","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/55e18311c705cceef6c34d522ea387b1f0069bab","name":"https://git.kernel.org/stable/c/55e18311c705cceef6c34d522ea387b1f0069bab","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/2677f97a67fdbc62a82ce1faa67791f54451d36f","name":"https://git.kernel.org/stable/c/2677f97a67fdbc62a82ce1faa67791f54451d36f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-93237","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93237","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7b09f5af01ede480cbe7abcb281cf17550a46ff5 ab275a23b4d9f04ca6c2f5f6a3246194e045a761 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7b09f5af01ede480cbe7abcb281cf17550a46ff5 55e18311c705cceef6c34d522ea387b1f0069bab git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7b09f5af01ede480cbe7abcb281cf17550a46ff5 2677f97a67fdbc62a82ce1faa67791f54451d36f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.2","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.2 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.51 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.5 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"93237","cve":"CVE-2026-93237","epss":"0.001730000","percentile":"0.060130000","score_date":"2026-09-27","updated_at":"2026-09-28 00:02:24"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["arch/loongarch/include/asm/pgtable.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"ab275a23b4d9f04ca6c2f5f6a3246194e045a761","status":"affected","version":"7b09f5af01ede480cbe7abcb281cf17550a46ff5","versionType":"git"},{"lessThan":"55e18311c705cceef6c34d522ea387b1f0069bab","status":"affected","version":"7b09f5af01ede480cbe7abcb281cf17550a46ff5","versionType":"git"},{"lessThan":"2677f97a67fdbc62a82ce1faa67791f54451d36f","status":"affected","version":"7b09f5af01ede480cbe7abcb281cf17550a46ff5","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["arch/loongarch/include/asm/pgtable.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.2"},{"lessThan":"6.2","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.51","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.51","versionStartIncluding":"6.2","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.5","versionStartIncluding":"6.2","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"6.2","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add DIRECT_MAP_PHYSMEM_END definition\n\nget_free_mem_region() and mhp_get_pluggable_range() bound their search\nto DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback\nin include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is\n(1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not\nadapt to the CPU's physical address space bits (cpu_pabits, probed from\nCPUCFG1).\n\nThe vmemmap window only covers physical space below 2^(cpu_pabits+1)\n(i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than\nMAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return\na ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then\nwraps the memmap range around and maps it into low memory, silently\ncorrupting the page tables. The same search also picked the top-of-\naddress-space region that crashed memmap_init_zone_device() with amdkfd\non Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 (\"LoongArch/mm:\nalign vmemmap to maximal folio size\") keeps that region in bounds on\ncurrent Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g.\nthe Loongson-2K series) are still affected.\n\nDefine DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range,\n(1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1\nunder CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d (\"riscv: mm:\nDefine DIRECT_MAP_PHYSMEM_END\").\n\n[1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/"}],"metrics":[{"cvssV3_1":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:L - 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.\nAC:L - 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.\nPR:L - 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.\nUI:N - 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.\nS:U - 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.\nC:H - __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.\nI:H - 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.\nA:H - 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."}]}],"providerMetadata":{"dateUpdated":"2026-09-25T12:42:39.505Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/ab275a23b4d9f04ca6c2f5f6a3246194e045a761"},{"url":"https://git.kernel.org/stable/c/55e18311c705cceef6c34d522ea387b1f0069bab"},{"url":"https://git.kernel.org/stable/c/2677f97a67fdbc62a82ce1faa67791f54451d36f"}],"title":"LoongArch: Add DIRECT_MAP_PHYSMEM_END definition","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-93237","datePublished":"2026-09-24T15:33:51.702Z","dateReserved":"2026-09-17T16:02:15.095Z","dateUpdated":"2026-09-25T12:42:39.505Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-24 16:17:19","lastModifiedDate":"2026-09-25 13:17:17","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"93237","Ordinal":"1","Title":"LoongArch: Add DIRECT_MAP_PHYSMEM_END definition","CVE":"CVE-2026-93237","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"93237","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add DIRECT_MAP_PHYSMEM_END definition\n\nget_free_mem_region() and mhp_get_pluggable_range() bound their search\nto DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback\nin include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is\n(1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not\nadapt to the CPU's physical address space bits (cpu_pabits, probed from\nCPUCFG1).\n\nThe vmemmap window only covers physical space below 2^(cpu_pabits+1)\n(i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than\nMAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return\na ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then\nwraps the memmap range around and maps it into low memory, silently\ncorrupting the page tables. The same search also picked the top-of-\naddress-space region that crashed memmap_init_zone_device() with amdkfd\non Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 (\"LoongArch/mm:\nalign vmemmap to maximal folio size\") keeps that region in bounds on\ncurrent Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g.\nthe Loongson-2K series) are still affected.\n\nDefine DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range,\n(1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1\nunder CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d (\"riscv: mm:\nDefine DIRECT_MAP_PHYSMEM_END\").\n\n[1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/","Type":"Description","Title":"LoongArch: Add DIRECT_MAP_PHYSMEM_END definition"}]}}}