CVE-2026-98431: RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency
In the Linux kernel, the following vulnerability has been resolved:
RDMA/uverbs: Fix mmaplock/disassociationlock circular dependency
Commit 51976c6cd786 ("RDMA/core: Provide rdmausermmapdisassociate() to disassociate mmap pages") introduced disassociationlock to protect new mmap registrations against uverbsusermmapdisassociate(), but created an ABBA deadlock:
Thread A (mmap / fork): mmaplock -> disassociationlock
Thread B (disassociate): disassociationlock -> mmaplock
Fix by removing disassociationlock entirely and using the pre-existing hwdestroyrwsem instead. hwdestroyrwsem already provides the same protection: rdmaumapopen() and ibuverbsmmap() both use downreadtrylock() before registering a new VMA, so holding hwdestroyrwsem in uverbsusermmapdisassociate() is sufficient to block new registrations. trylock is used in both mmap paths (not blocking downread) because mmaplock is already held on entry, and uverbsusermmapdisassociate() acquires mmaplock internally — a blocking read would recreate the same deadlock.
The only caller that was not taking hwdestroyrwsem for write was rdmausermmapdisassociate(). Fix it to take the rwsem per-ufile while iterating under listsmutex. This is safe because ibuverbsclose() releases hwdestroyrwsem entirely before acquiring listsmutex, so the two locks are never held simultaneously.
lockdep warning:
[ 776.654252] ====================================================== [ 776.655214] WARNING: possible circular locking dependency detected [ 776.656167] 6.18.0for-upstreamdebug94e244d9ccab #1 Not tainted [ 776.657114] ------------------------------------------------------ [ 776.658087] devlink/14824 is trying to acquire lock: [ 776.658879] ffff88811170c800 (&mm->mmaplock){++++}-{4:4}, at: uverbsusermmapdisassociate+0x168/0x780 [ibuverbs] [ 776.660479] [ 776.660479] but task is already holding lock: [ 776.661460] ffff888142d92b08 (&file->disassociationlock){+.+.}-{4:4}, at: uverbsusermmapdisassociate+0x39/0x780 [ibuverbs] [ 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->disassociationlock){+.+.}-{4:4}: [ 776.666887] mutexlock+0x16d/0x2330 [ 776.667633] rdmaumapopen+0x129/0x280 [ibuverbs] [ 776.668489] dupmmap+0xa40/0x1790 [ 776.669170] copyprocess+0x5dd2/0x6170 [ 776.669933] kernelclone+0xb6/0x610 [ 776.670636] dosysclone+0xb5/0xf0 [ 776.671354] dosyscall64+0x70/0x12e0 [ 776.672083] entrySYSCALL64afterhwframe+0x4b/0x53 [ 776.672940] [ 776.672940] -> #1 (&mm->mmaplock/1){+.+.}-{4:4}: [ 776.673985] downwritenested+0x90/0x1e0 [ 776.674751] dupmmap+0x201/0x1790 [ 776.675448] copyprocess+0x5dd2/0x6170 [ 776.676180] kernelclone+0xb6/0x610 [ 776.676904] dosysclone+0xb5/0xf0 [ 776.677615] dosyscall64+0x70/0x12e0 [ 776.678351] entrySYSCALL64afterhwframe+0x4b/0x53 [ 776.679239] [ 776.679239] -> #0 (&mm->mmaplock){++++}-{4:4}: [ 776.680253] lockacquire+0x18c6/0x2ec0 [ 776.681018] lockacquire+0x10e/0x2e0 [ 776.681742] downread+0x95/0x430 [ 776.682395] uverbsusermmapdisassociate+0x168/0x780 [ibuverbs] [ 776.683436] uverbsdestroyufilehw+0x1ae/0x270 [ibuverbs] [ 776.684416] ibuverbsremoveone+0x22b/0x420 [ibuverbs] [ 776.685371] removeclientcontext+0xa6/0xf0 [ibcore] [ 776.686342] disabledevice+0x12b/0x240 [ibcore] [ 776.687249] ibunregisterdevice+0x269/0x460 [ibcore] [ 776.688233] ibunregisterdevice+0x21/0x30 [ibcore] [ 776.689140] mlx5rremove+0xd0/0x170 [mlx5ib] [ 776.689999] devicereleasedriverinternal+0x3b2/0x5 ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch 51976c6cd786
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
The issue requires concurrent activity involving RDMA uverbs user mmap handling: one thread performing mmap or fork while another disassociates mmap pages. The conflicting lock order is mmap_lock then disassociation_lock in the mmap/fork path, versus disassociation_lock then mmap_lock in the disassociation path.
What is the operational impact if the issue is triggered?
The two threads can form an ABBA circular lock dependency and deadlock. This can leave the involved mmap/fork and disassociation operations unable to proceed.
What change resolves the locking conflict?
The fix removes disassociation_lock and uses the existing hw_destroy_rwsem to prevent new VMA registrations during disassociation. The mmap paths use a non-blocking read trylock because mmap_lock is already held when they run, while disassociation acquires mmap_lock internally.