CVE-2026-97905 in Linux
الملخص
بحسب VulDB • 25/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
cpufreq: تهيئة مصفوفة المعالجات (cpumask) الخاصة بالسياسة إلى أصفار قبل نشرها عبر sysfs
تقوم دالة `cpufreq_policy_alloc()` بتخصيص `policy->cpus` باستخدام `alloc_cpumask_var()، أي بدون استخدام العلم `__GFP_ZERO`. وعلى عكس ذلك، فإن مصفوفتي `related_cpus` و `real_cpus` الشقيقتين تستخدمان التهيئة إلى الأصفار. وعندما يكون الخيار `CONFIG_CPUMASK_OFFSTACK=y` مفعلاً، تكون المصفوفة تخصيصاً منفصلاً عبر `kmalloc_node()`، وبالتالي يحتوي.bitmap الخاص بها على أي بيانات تركها مُخصِّم الذاكرة (slab allocator) خلفه:
cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap غير مهيأ */ kobject_init_and_add() /* يظهر policy%u/ في sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* أول قيمة صالحة */
يؤدي هذا إلى وجود نافذة زمنية تكون فيها سمات (attributes) sysfs قابلة للوصول بالفعل، بينما لا يزال `policy->cpus` يحتوي على بيانات عشوائية. تعتمد دالتا العرض (`show()`) والتخزين (`store()`) على التحقق من `policy_is_inactive()`، أي أن مصفوفة المعالجات فارغة (`cpumask_empty(policy->cpus)`). لذا، فإن وجود bitmap غير صفري يجعل هذه الدوال تستدعي معاملات السمات (attribute callbacks) على سياسة لم يتم تهيئتها بعد.
يتم إصلاح هذا الخطأ باستخدام `zalloc_cpumask_var()` لتخصيص `policy->cpus`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.