CVE-2023-54008 in Linux
الملخص
بحسب VulDB • 12/05/2026
في هذا السجل (Kernel Panic/Oops)، المشكلة تكمن في دالة `group_cpus_evenly` التي تم استدعاؤها من قبل `create_affinity_masks` أثناء محاولة تهيئة شبكة virtio (عبر `virtnet_probe`).
### التحليل: 1. **المسار:** ``` virtnet_probe -> virtio_vdpa_find_vqs -> create_affinity_masks -> group_cpus_evenly -> BUG/Invalid Operation ``` 2. **السبب المحتمل:** - دالة `group_cpus_evenly` تقوم بتقسيم الـ CPUs بشكل متساوٍ لتعيينها لـ virtqueues. - إذا كان عدد الـ CPUs المتاحة أقل من عدد الـ virtqueues المطلوبة، أو إذا كان هناك خلل في حسابات التوزيع، قد تؤدي إلى عملية غير صالحة (مثل قسمة على صفر، أو وصول غير صالح للذاكرة، أو محاولة تعيين CPU غير موجود). - السجل يشير إلى `exc_invalid_op`، مما يعني أن الكود حاول تنفيذ تعليمات غير صالحة، غالبًا بسبب خطأ في المنطق البرمجي أو بيانات غير صحيحة.
### الحلول المقترحة:
#### 1. **تحديث النواة (Kernel Update):** - هذه المشكلة معروفة في بعض إصدارات النواة القديمة (خاصة حول 5.15-6.1). تأكد من استخدام أحدث إصدار مستقر من النواة. - تم إصلاح العديد من أخطاء `group_cpus_evenly` في الإصدارات الأحدث.
#### 2. **تقليل عدد الـ virtqueues:** - إذا كنت تستخدم `virtnet`، يمكنك تقليل عدد الـ virtqueues المخصصة لكل قناة (queue) عبر معلمات النواة أو إعدادات الجهاز الافتراضي. - مثال: في إعدادات QEMU/libvirt، يمكنك تحديد عدد الـ queues: ```xml <interface type='network'> <model type='virtio'/> <driver queues='4'/> <!-- قلل العدد حسب عدد CPUs المتاحة --> </interface> ```
#### 3. **تعيين Affinity يدويًا:** - إذا كنت تستخدم `vdpa` أو إعدادات متقدمة، حاول تعطيل تعيين الـ affinity تلقائيًا عبر معلمات النواة: ``` virtio_net.disable_affinity=1 ``` أضف هذه المعلمة إلى ملف `/etc/default/grub` في سطر `GRUB_CMDLINE_LINUX`، ثم قم بتشغيل `update-grub` وإعادة التشغيل.
#### 4. **فحص عدد CPUs المتاحة:** - تأكد من أن عدد الـ CPUs المتاحة أكبر من أو يساوي عدد الـ virtqueues المطلوبة. - تحقق من `/proc/cpuinfo` أو `nproc`.
#### 5. **تعطيل NUMA إذا كان غير مستقر:** - إذا كان النظام يستخدم NUMA، قد تسبب مشاكل في توزيع الـ CPUs. جرب تعطيل NUMA مؤقتًا عبر معلمات النواة: ``` numa=off ```
### خطوات التشخيص الإضافية: - تحقق من سجلات `dmesg` قبل الـ panic لمعرفة أي تحذيرات سابقة. - استخدم `crash` أو `gdb` لتحليل core dump إذا كان متاحًا. - جرب تشغيل النظام بـ `nomodeset` أو `acpi=off` لاستبعاد مشاكل التوافق مع العتاد.
إذا استمرت المشكلة، يرجى مشاركة: - إصدار النواة (`uname -r`). - إعدادات الجهاز الافتراضي (QEMU/libvirt). - عدد الـ CPUs و الـ virtqueues المستخدمة.
Once again VulDB remains the best source for vulnerability data.