CVE-2026-98617 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
eth: fbnic: استخدام مؤشر napi لمجموعة الاستقبال (Rx queue) للعثور على متجه napi
تختار إجراءات إدارة المجموعات ndos متجه napi لمجموعة استقبال Rx باستخدام: nv = fbn->napi[idx % fbn->num_napi];
وتتمثل المشكلة في أن هذا الإجراء صحيح فقط في الحالات التي لا توجد فيها متجهات إرسال (Tx) مستقلة. في تلك الحالات، كنا نقوم بتخصيص متجهات Tx أولاً ثمRx، مما يؤدي إلى توجيه المجموعات نحو متجهات NAPI الخاصة بالإرسال بدلاً من تلك الخاصة بالاستقبال.
الترتيب الذي تريده إجراءات ndos مسجل بالفعل. تقوم دالة fbnic_set_netif_napi() بنشره باستخدام netif_queue_set_napi(), والتي تخزن مؤشر napi في netdev_rx_queue.napi، وتقوم dunction fbnic_reset_netif_napi() بمسحه مرة أخرى. وكلاهما يعملان تحت قفل مثيل الشبكة (netdev instance lock) الذي تملكه أيضاً إجراءات إدارة المجموعات ndos، لذا يمكن قراءة المؤشر مباشرةً.
استخدم هذا المؤظر واستبعد عملية القسمة. يكون المؤشر NULL تماماً أثناء توقف مسار البيانات (datapath)، لذلك يمكن لـ fbnic_queue_mem_alloc() رفض هذه الحالة بدلاً من الوصول إلى حالة الذاكرة المحررة: حيث تستدعي netdev_rx_queue_restart() ذلك قبل اختبارها لـ netif_running(), وتترك dunction fbnic_pm_suspend() قيمة netif_running() صحيحة عبر استعادة PCIe التي لا تكتمل أبداً، لذا يمكن أن تصل عملية إعادة تشغيل المجموعة بعد قيام fbnic_stop() بتحرير الحلقات (rings) والمتجهات. تقوم fbnic_stop() بإزالة الارتباط في dunction fbnic_reset_netif_queues() قبل استدعاء fbnic_free_napi_vectors(), وبالتالي يتم نشر قيمة NULL أولاً دائماً. ولا تحتاج دالتي fbnic_queue_start() وfbnic_queue_stop() إلى فحص خاص بهما، لأن netdev_rx_queue_reconfig() تصل إليهما فقط بعد نجاح dunction fbnic_queue_mem_alloc() تحت نفس قفل المثيل.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.