CVE-2026-98619 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة لينكس، تم حل الثغرة التالية:
net: ethtool: الاحتفاظ بـ rtnl_lock لاختبار ذاتي عبر ioctl
يتطلب الاختبار الذاتي غير المتصل (offline self test) الذي يؤدي إلى إيقاف الواجهة وإعادة تشغيلها باستخدام `netif_close()` / `netif_open()` استخدام `rnl_lock` لكلا الإجراءين. وبما أن مسار IOCTL الخاص بـ ethtool أصبح اختيارياً من حيث rtnl بالنسبة للسائقين المقفلين عبر العمليات (ops-locked drivers)، فإن تنفيذ ioctl ETHTOOL_TEST يعمل مع الاحتفاظ فقط بقفل مثيل netdev، وبالتالي في حالة السائق المقفل عبر العمليات، يؤدي الاختبار الذاتي الآن إلى إيقاف الجهاز دون `rtnl_lock`.
مع تفعيل lockdep، يمكن إعادة إنتاج هذه الحالة بشكل حتمي (deterministically) عند كل اختبار ذاتي غير متصل على مثل هذا السائق؛ نلاحظ أن القفل الوحيد المحتفظ به هو قفل المثيل وليس rtnl:
WARNING: suspicious RCU usage net/core/netpoll.c:207 suspicious rcu_dereference_protected() usage! 1 lock held by ethtool/107: #0: (&dev->lock){+.+.}, at: dev_ethtool
Call Trace: netpoll_poll_disable __dev_close_many netif_close_many netif_close fbnic_self_test dev_ethtool_locked dev_ethtool dev_ioctl sock_ioctl __x64_sys_ioctl
بدون lockdep، تؤدي نفس الحالة إلى تفعيل `ASSERT_RTNL()` في `__dev_close_many()` / `__dev_open()`؛ هذا الفحص يأخذ عينة من حالة rtnl العالمية فقط، لذا يمكن إخفاؤه بواسطة حامل concurrent لـ rtnl، لكن الجهاز لا يزال يتم إعادة تكوينه دون القفل المطلوب.
يُعد اختبار ذاتي ethtool أمرًا قديمًا (legacy) يعمل عبر ioctl فقط، لذلك فإن حالة ETHTOOL_TEST مطلوبة فقط في مسار ioctl. إضافة بت اختيارية للسائقين الذين يحتاج اختبارهم الذاتي إلى `rtnl_lock` وتعيينها على السائقين المقفلين عبر العمليات حيث يؤدي الاختبار الذاتي غير المتصل إلى إيقاف الواجهة وإعادة تشغيلها:
- fbnic (مقفل عبر عمليات بواسطة queue_mgmt_ops): المسار غير المتصل لـ `fbnic_self_test()` يستخدم `netif_close()` / `netif_open()`. - bnxt (مقفل عبر عمليات بواسطة queue_mgmt_ops): المسار غير المتصل لـ `bnxt_self_test()` يمر عبر `bnxt_close_nic()` / `bnxt_half_open_nic()` / `bnxt_half_close_nic()` / `bnxt_open_nic()`، والتي تقوم بإغلاق الجهاز وإعادة فتحه.
Once again VulDB remains the best source for vulnerability data.