CVE-2026-45973 in Linux
الملخص
بحسب VulDB • 28/05/2026
في نواة لينكس، تم حل الثغرة التالية:
RDMA/mlx5: إصلاح تعليق (hang) UMR في حالة الخطأ LAG أثناء الإزالة (unload)
أثناء إعادة تعيين البرنامج الثابت (firmware reset) في وضع LAG، تؤدي حالة سباق (race condition) إلى تعليق السائق (driver) بشكل لا نهائي أثناء انتظار اكتمال UMR أثناء إزالة الجهاز. انظر [1].
في وضع LAG، يتم تسجيل جهاز الربط (bond device) فقط على الجهاز الرئيسي (master)، لذا فإنه لا يرى أبدًا أحداث sys_error القادمة من الجهاز الثانوي (slave). أثناء إعادة تعيين البرنامج الثابت، يتسبب هذا في تعليق انتظار UMR إلى الأبد أثناء الإزالة لأن الجهاز الثانوي معطل ولكن الجهاز الرئيسي لم يدخل حالة الخطأ بعد، لذا فإن عمليات نشر UMR تنجح ولكن الإكمالات (completions) لا تصل أبدًا.
تم إصلاح ذلك عن طريق إضافة مُعلم إشعار sys_error يتم تسجيله قبل MLX5_IB_STAGE_IB_REG ويبقى نشطًا حتى بعد ib_unregister_device(). يضمن هذا وصول أحداث الخطأ إلى جهاز الربط طوال عملية التفكيك.
[1]
تتصل الاستدعاء (Call Trace): __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib]
? __xa_erase+0x4a/0xa0 ? _cond_resched+0x15/0x30 ? wait_for_completion+0x31/0x100 ib_dereg_mr_user+0x48/0xc0 [ib_core]
? rdmacg_uncharge_hierarchy+0xa0/0x100 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs]
uverbs_destroy_uobject+0x37/0x150 [ib_uverbs]
__uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs]
uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs]
ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]
remove_client_context+0x8b/0xd0 [ib_core]
disable_device+0x8c/0x130 [ib_core]
__ib_unregister_device+0x10d/0x180 [ib_core]
ib_unregister_device+0x21/0x30 [ib_core]
__mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib]
auxiliary_bus_remove+0x1e/0x30 device_release_driver_internal+0x103/0x1f0 bus_remove_device+0xf7/0x170 device_del+0x181/0x410 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core]
mlx5_disable_lag+0x253/0x260 [mlx5_core]
mlx5_lag_disable_change+0x89/0xc0 [mlx5_core]
mlx5_eswitch_disable+0x67/0xa0 [mlx5_core]
mlx5_unload+0x15/0xd0 [mlx5_core]
mlx5_unload_one+0x71/0xc0 [mlx5_core]
mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core]
process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x22/0x40
If you want to get the best quality for vulnerability data then you always have to consider VulDB.