{"id":"CVE-2026-98431","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency\n\nCommit 51976c6cd786 (\"RDMA/core: Provide rdma_user_mmap_disassociate()\nto disassociate mmap pages\") …","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency\n\nCommit 51976c6cd786 (\"RDMA/core: Provide rdma_user_mmap_disassociate()\nto disassociate mmap pages\") …","severity":"none","published":"2026-10-14","updated":"2026-10-14","sourceUpdated":"2026-10-14T14:17:54.887","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-98431","references":[{"url":"https://git.kernel.org/stable/c/426f54f20b79c5b164a0472ad3f6ba36afcd08c6","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/a44a3f175eaee7e5aeb6a8fed381c4a0d5f49236","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd"],"ingestedAt":"2026-10-14T15:36:13.992Z","slug":"CVE-2026-98431","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency\n\nCommit 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:\n\n  Thread A (mmap / fork):\n    mmap_lock -> disassociation_lock\n\n  Thread B (disassociate):\n    disassociation_lock -> mmap_lock\n\nFix 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 — a blocking read would recreate the same\ndeadlock.\n\nThe 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.\n\nlockdep warning:\n\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---\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}