CVE-2026-97988 in Linux
الملخص
بحسب VulDB • 25/09/2026
في نواة لينكس، تم حل الثغرة التالية:
vhost: إبطال وصول vring عند انتقالات IOTLB
عندما يتغير VIRTIO_F_ACCESS_PLATFORM، تُفسر مؤشرات vring المخزنة وبيانات IOTLB في مساحة عنوان مختلفة. قد يؤدي الاحتفاظ بها عبر الانتقال إلى ترك تعاريج حلقات قديمة (stale) قيد الاستخدام.
يؤدي مسح d->iotlb قبل أخذ أقفال VQ أيضًا إلى السماح لعميل بملاحظة قيمة d->iotlb عابرة تساوي NULL والعودة إلى d->umem أثناء ترجمة واصف (descriptor).
أضف مساعدًا مشتركًا باسم vhost_clear_device_iotlb() لكل من vhost-net وvhost-vsock. خذ جميع أقفال VQ حسب الترتيب الفهرسي قبل إسقاط IOTLB على مستوى الجهاز، وأبطل وصول الحلقة المخزن والبيانات الوصفية الخاصة بكل VQ، وامسح رسائل IOTLB المعلقة، وقم بتحرير الجدول القديم بعد التسليم (handoff). وهذا يُنشئ تسلسلًا للتحول مع العملاء ويمنع تعاريج مساحات عناوين مختلطة.
في أول انتقال مباشر إلى IOTLB، أبطل العناوين المخزنة لـ vring. عند استبدال IOTLB لجهاز موجود، حافظ على عناوين حلقة GIOVA وأعد ضبط ذاكرة التخزين المؤقت للبيانات الوصفية فقط. بعد مسح ACCESS_PLATFORM، يجب أن يقوم المستخدم (userspace) بتكوين عناوين vring لنمط العنوان الجديد.
تقوم دالة vhost_vq_invalidate_access() بإبطال desc وavail وused معًا. تعامل VQ على أنها ملغاة الوصول فقط عندما تكون جميع القيم الثلاث NULL، نظرًا لأن عنوان GIOVA واحد قد يكون صفرًا بشكل شرعي.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.