In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
RDMA\/uverbs: Fix mmap_lock\/disassociation_lock circular dependency<\/p>\n
Commit 51976c6cd786 (“RDMA\/core: Provide rdma_user_mmap_disassociate()
\nto disassociate mmap pages”) introduced disassociation_lock to protect
\nnew mmap registrations against uverbs_user_mmap_disassociate(), but
\ncreated an ABBA deadlock:<\/p>\n
Thread A (mmap \/ fork):
\n mmap_lock -> disassociation_lock<\/p>\n
Thread B (disassociate):
\n disassociation_lock -> mmap_lock<\/p>\n
Fix by removing disassociation_lock entirely and using the pre-existing
\nhw_destroy_rwsem instead. hw_destroy_rwsem already provides the same
\nprotection: rdma_umap_open() and ib_uverbs_mmap() both use
\ndown_read_trylock() before registering a new VMA, so holding hw_destroy_rwsem
\nin uverbs_user_mmap_disassociate() is sufficient to block new registrations.
\ntrylock is used in both mmap paths (not blocking down_read) because
\nmmap_lock is already held on entry, and uverbs_user_mmap_disassociate()
\nacquires mmap_lock internally \u2014 a blocking read would recreate the same
\ndeadlock.<\/p>\n
The only caller that was not taking hw_destroy_rwsem for write was
\nrdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile while
\niterating under lists_mutex. This is safe because ib_uverbs_close()
\nreleases hw_destroy_rwsem entirely before acquiring lists_mutex, so the
\ntwo locks are never held simultaneously.<\/p>\n
lockdep warning:<\/p>\n
[ 776.654252] ======================================================
\n [ 776.655214] WARNING: possible circular locking dependency detected
\n [ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted
\n [ 776.657114] ——————————————————
\n [ 776.658087] devlink\/14824 is trying to acquire lock:
\n [ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168\/0x780 [ib_uverbs]
\n [ 776.660479]
\n [ 776.660479] but task is already holding lock:
\n [ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39\/0x780 [ib_uverbs]
\n [ 776.663177]
\n [ 776.663177] which lock already depends on the new lock.
\n [ 776.663177]
\n [ 776.664525]
\n [ 776.664525] the existing dependency chain (in reverse order) is:
\n [ 776.665724]
\n [ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}:
\n [ 776.666887] __mutex_lock+0x16d\/0x2330
\n [ 776.667633] rdma_umap_open+0x129\/0x280 [ib_uverbs]
\n [ 776.668489] dup_mmap+0xa40\/0x1790
\n [ 776.669170] copy_process+0x5dd2\/0x6170
\n [ 776.669933] kernel_clone+0xb6\/0x610
\n [ 776.670636] __do_sys_clone+0xb5\/0xf0
\n [ 776.671354] do_syscall_64+0x70\/0x12e0
\n [ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b\/0x53
\n [ 776.672940]
\n [ 776.672940] -> #1 (&mm->mmap_lock\/1){+.+.}-{4:4}:
\n [ 776.673985] down_write_nested+0x90\/0x1e0
\n [ 776.674751] dup_mmap+0x201\/0x1790
\n [ 776.675448] copy_process+0x5dd2\/0x6170
\n [ 776.676180] kernel_clone+0xb6\/0x610
\n [ 776.676904] __do_sys_clone+0xb5\/0xf0
\n [ 776.677615] do_syscall_64+0x70\/0x12e0
\n [ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b\/0x53
\n [ 776.679239]
\n [ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}:
\n [ 776.680253] __lock_acquire+0x18c6\/0x2ec0
\n [ 776.681018] lock_acquire+0x10e\/0x2e0
\n [ 776.681742] down_read+0x95\/0x430
\n [ 776.682395] uverbs_user_mmap_disassociate+0x168\/0x780 [ib_uverbs]
\n [ 776.683436] uverbs_destroy_ufile_hw+0x1ae\/0x270 [ib_uverbs]
\n [ 776.684416] ib_uverbs_remove_one+0x22b\/0x420 [ib_uverbs]
\n [ 776.685371] remove_client_context+0xa6\/0xf0 [ib_core]
\n [ 776.686342] disable_device+0x12b\/0x240 [ib_core]
\n [ 776.687249] __ib_unregister_device+0x269\/0x460 [ib_core]
\n [ 776.688233] ib_unregister_device+0x21\/0x30 [ib_core]
\n [ 776.689140] mlx5r_remove+0xd0\/0x170 [mlx5_ib]
\n [ 776.689999] device_release_driver_internal+0x3b2\/0x5
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
RDMA\/uverbs: Fix mmap_lock\/disassociation_lock circular dependency<\/p>\n
Commit 51976c6cd786 (“RDMA\/core: Provide rdma_user_mmap_disasso<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-39102","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/39102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=39102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=39102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=39102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}