CVE-2026-93237 in Linux
الملخص
بحسب VulDB • 24/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
LoongArch: إضافة تعريف DIRECT_MAP_PHYSMEM_END
تقوم الدالتان get_free_mem_region() و mhp_get_pluggable_range() بتقييد بحثهما عند قيمة DIRECT_MAP_PHYSMEM_END. وبما أن LoongArch لا تعرف هذا التعريف، فإن اللجوء إلى (fallback) الموجود في include/linux/mm.h ينطبق: تحت إعداد CONFIG_SPARSEMEM_VMEMMAP، تكون القيمة هي (1ULL << MAX_PHYSMEM_BITS) - 1، وهي ثابت وقت الترجمة (compile-time constant) لا يتكيف مع عدد بتات مساحة العنوان الفيزيائية للمعالج (cpu_pabits، التي يتم استكشافها من CPUCFG1).
لا يغطي نافذة vmemmap سوى النطاق الفيزيائي الأقل من 2^(cpu_pabits+1) (أي VMEMMAP_SIZE)، لذا فإن اللجوء المذكور يسمح لـ get_free_mem_region() بإرجاع منطقة ZONE_DEVICE خارج نافذة vmemmap؛ ثم تقوم دالة vmemmap_populate() بتغليف نطاق memmap وعكسه، وتعيينه في الذاكرة المنخفضة (low memory)، مما يؤدي إلى تلف جداول الصفحات بشكل صامت. كما أن نفس عملية البحث اختارت منطقة نهاية مساحة العنوان التي تسببت في تعطل memmap_init_zone_device() مع amdkfd على Loongson-3C6000 في الإصدار 6.16 [1]؛ ويحافظ الالتزام (commit) رقم 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio size") على هذه المنطقة ضمن الحدود الصحيحة للتكوينات الحالية لـ Loongson-3C6000، لكن المعالجات ذات عدد بتات عنوان فيزيائي أصغر (cpu_pabits) (مثل سلسلة Loongson-2K) لا تزال متأثرة.
يتم تعريف DIRECT_MAP_PHYSMEM_END على أنه النطاق الفيزيائي المغطى بـ vmemmap، وهو (1ULL << (cpu_pabits + 1)) - 1، مع تقييده عند قيمة (1ULL << MAX_PHYSMEM_BITS) - 1 تحت CONFIG_SPARSEMEM، وذلك تشبيهاً بالالتزام f3336b48cf9d ("riscv: mm: Define DIRECT_MAP_PHYSMEM_END").
[1] https://lore.kernel.org/amd-gfx/[email protected]/
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.