{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-93237 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-93237 is a high-severity memory corruption vulnerability in Linux, published on 24 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-93237 and fix it if it is affected.\n\nWhat it is: CVE-2026-93237 is a high-severity memory corruption vulnerability in Linux, published on 24 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-93237 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-93237/ (Markdown: https://insights.sbomify.com/CVE-2026-93237/index.md)","id":"CVE-2026-93237","markdown":"https://insights.sbomify.com/CVE-2026-93237/index.md","name":"CVE-2026-93237","record":{"aliases":["AZL-103640","BELL-CVE-2026-93237","DEBIAN-CVE-2026-93237","GHSA-883q-wh28-fg8c","UBUNTU-CVE-2026-93237"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"Missing memory boundary definition in LoongArch Linux kernel allows page table corruption and crashes on specific CPUs.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"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 \u003c\u003c 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 \u003c\u003c (cpu_pabits + 1)) - 1, capped at (1ULL \u003c\u003c 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/","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"LoongArch: Add DIRECT_MAP_PHYSMEM_END definition","id":"CVE-2026-93237","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap","id":"CVE-2026-93238"},"packages":[],"prev":{"headline":"media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common","id":"CVE-2026-93236"},"products":["Linux"],"published":"2026-09-24","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"Missing memory boundary definition in LoongArch Linux kernel allows page table corruption and crashes on specific CPUs.","url":"https://insights.sbomify.com/CVE-2026-93237/"}