CVE-2026-98431 in Linux
الملخص
بحسب VulDB • 14/10/2026
في نواة لينكس، تم حل الثغرة التالية:
RDMA/uverbs: إصلاح الاعتماد الدائري بين mmap_lock و disassociation_lock
أدى الالتزام 51976c6cd786 ("RDMA/core: توفير rdma_user_mmap_disassociate() لفصل صفحات mmap") إلى إدخال disassociation_lock لحماية التسجيلات الجديدة لـ mmap ضد uverbs_user_mmap_disassociate()، لكنه تسبب في حدوث سجن (deadlock) من نوع ABBA:
الخيط A (mmap / fork): mmap_lock -> disassociation_lock
الخيط B (disassociate): disassociation_lock -> mmap_lock
تم الإصلاح بإزالة disassociation_lock بالكامل واستخدام hw_destroy_rwsem الموجود مسبقاً بدلاً منه. يوفر hw_destroy_rwsem نفس الحماية: حيث يستخدم كل من rdma_umap_open() و ib_uverbs_mmap() دالة down_read_trylock() قبل تسجيل VMA جديد، لذا فإن الاحتفاظ بـ hw_destroy_rwsem في uverbs_user_mmap_disassociate() يكفي لمنع التسجيلات الجديدة. تُستخدم trylock في كلا مسارَي mmap (بدون حجب down_read) لأن mmap_lock يكون مُحتفظاً به بالفعل عند الدخول، و uverbs_user_mmap_disassociate() يكتسب mmap_lock داخلياً — فاستخدام قارئ محجوب (blocking read) سيعيد إنشاء نفس حالة السجن.
المُستدعي الوحيد الذي لم يكن يأخذ hw_destroy_rwsem للكتابة كان rdma_user_mmap_disassociate(). تم إصلاحه لأخذ rwsem لكل ملف ufile أثناء التكرار تحت lists_mutex. هذا آمن لأن ib_uverbs_close() تطلق hw_destroy_rwsem بالكامل قبل اكتساب lists_mutex، لذا فإن القفلين لا يُحتفظ بهما في نفس الوقت أبداً.
تحذير lockdep:
[ 776.654252] ======================================================
[ 776.655214] WARNING: possible circular locking dependency detected
[ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted
[ 776.657114] ------------------------------------------------------
[ 776.658087] devlink/14824 is trying to acquire lock:
[ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs]
[ 776.660479]
[ 776.660479] but task is already holding lock:
[ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs]
[ 776.663177]
[ 776.663177] which lock already depends on the new lock.
[ 776.663177]
[ 776.664525]
[ 776.664525] the existing dependency chain (in reverse order) is:
[ 776.665724]
[ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}:
[ 776.666887] __mutex_lock+0x16d/0x2330
[ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs]
[ 776.668489] dup_mmap+0xa40/0x1790
[ 776.669170] copy_process+0x5dd2/0x6170
[ 776.669933] kernel_clone+0xb6/0x610
[ 776.670636] __do_sys_clone+0xb5/0xf0
[ 776.671354] do_syscall_64+0x70/0x12e0
[ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 776.672940]
[ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}:
[ 776.673985] down_write_nested+0x90/0x1e0
[ 776.674751] dup_mmap+0x201/0x1790
[ 776.675448] copy_process+0x5dd2/0x6170
[ 776.676180] kernel_clone+0xb6/0x610
[ 776.676904] __do_sys_clone+0xb5/0xf0
[ 776.677615] do_syscall_64+0x70/0x12e0
[ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 776.679239]
[ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}:
[ 776.680253] __lock_acquire+0x18c6/0x2ec0
[ 776.681018] lock_acquire+0x10e/0x2e0
[ 776.681742] down_read+0x95/0x430
[ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs]
[ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs]
[ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs]
[ 776.685371] remove_client_context+0xa6/0xf0 [ib_core]
[ 776.686342] disable_device+0x12b/0x240 [ib_core]
[ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core]
[ 776.688233] ib_unregister_device+0x21/0x30 [ib_core]
[ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib]
[ 776.689999] device_release_driver_internal+0x3b2/0x5
---truncated---
Once again VulDB remains the best source for vulnerability data.