CVE-2026-80895 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة Linux، تم إصلاح الثغرة التالية:
mshv: ترتيب نشر مصفوفة pt_vp_array مقابل مسار تأكيد irqfd
تقوم الدالة mshv_partition_ioctl_create_vp() بتهيئة هيكل VP (بما في ذلك عمليات التخصيص، و mutex_init، و init_waitqueue_head، وتعيينات الصفحات) ثم تنشر المؤشر داخل partition->pt_vp_array. تقرأ عدة مسارات ISR هذه المصفوفة بدون قفل: وهي مسار اعتراض ISR، ومساري جدولة ISRs، ودالة mshv_try_assert_irq_fast() في المسار السريع لـ irqfd.
من بين هذه المسارات، فقط mshv_try_assert_irq_fast() يمكن أن تتسابق هيكلياً مع عملية النشر. فهي تعمل من مستيقظ eventfd دون الاحتفاظ بـ pt_mutex، ولا يتطلب MSHV_IRQFD أن يشير المعرف المستهدف lapic_apic_id (المساوي لـ vp_index) إلى VP موجود عند وقت التسجيل. لذلك، يمكن للمستخدم تسجيل irqfd يستهدف VP لم يتم إنشاؤه بعد، ثم تشغيل mshv_try_assert_irq_fast() بشكل متزامن مع MSHV_CREATE_VP لنفس الفهرس. على المعماريات ذات الترتيب الضعيف (weakly-ordered architectures)، قد يلاحظ القارئ مؤشراً غير NULL في pt_vp_array قبل أن تصبح عمليات الكتابة الأولية لتهيئة هيكل VP مرئية، مما يؤدي إلى استخدام حقول تم تهيئتها جزئياً (مثل vp_register_page).
لا يمكن للمسارات الأخرى لقراءات ISR الوصول إلى هذا التسابق: فلن يولد المضيف الافتراضي رسائل اعتراض أو جدولة لـ VP لم يُخبر قط بأنه يعمل، ويمكن للمستخدم فقط استدعاء MSHV_RUN_VP على ملف الواجهة الخاص بـ VP الذي تم إرجاعه بواسطة MSHV_CREATE_VP، والذي يتم إرجاعه بشكل بنائي بعد النشر. اترك هؤلاء القراء كعمليات تحميل عادية (plain loads).
استخدم smp_store_release() في mshv_partition_ioctl_create_vp() لنشر المؤشر، وقابله مع smp_load_acquire() في mshv_try_assert_irq_fast(). على x86، تتحول هذه إلى عمليات وصول عادية تحت TSO؛ وعلى ARM64، تنتج حواجز acquire/release ذات تعليمات واحدة، وهو أمر مقبول في هذا المسار السريع.
يحتوي مسار الجانب الخاص بالتدمير (destroy_partition() الذي يمسح pt_vp_array[i] ليصبح NULL بعد kfree(vp)) على مخاوف منفصلة بشأن الترتيب وعمر الكائن خارج نطاق هذه المناقشة.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.