https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 20:18:39 +0000 https://vulnerability.circl.lu/vuln/cve-2026-93237 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>LoongArch: Add DIRECT_MAP_PHYSMEM_END definition</p> <p>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 &lt;&lt; MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not adapt to the CPU&#39;s physical address space bits (cpu_pabits, probed from CPUCFG1).</p> <p>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 (&#34;LoongArch/mm: align vmemmap to maximal folio size&#34;) 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.</p> <p>Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range, (1ULL &lt;&lt; (cpu_pabits + 1)) - 1, capped at (1ULL &lt;&lt; MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d (&#34;riscv: mm: Define DIRECT_MAP_PHYSMEM_END&#34;).</p> <p>[1] https://lore.ker…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>LoongArch: Add DIRECT_MAP_PHYSMEM_END definition</p> <p>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 &lt;&lt; MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not adapt to the CPU&#39;s physical address space bits (cpu_pabits, probed from CPUCFG1).</p> <p>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 (&#34;LoongArch/mm: align vmemmap to maximal folio size&#34;) 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.</p> <p>Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range, (1ULL &lt;&lt; (cpu_pabits + 1)) - 1, capped at (1ULL &lt;&lt; MAX_PHYSMEM_BITS) - 1 under CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d (&#34;riscv: mm: Define DIRECT_MAP_PHYSMEM_END&#34;).</p> <p>[1] https://lore.ker…</p> https://vulnerability.circl.lu/vuln/cve-2026-93237