CVE-2026-98431

In the Linux kernel, the following vulnerability has been resolved:

RDMA/uverbs: Fix mmap lock/disassociation lock circular dependency

Commit 51976c6cd786 ("RDMA/core: Provide rdma user mmap disassociate() to disassociate mmap pages") introduced disassociation lock to protect new mmap registrations against uverbs user mmap disassociate(), but created an ABBA deadlock:

Thread A (mmap / fork): mmap lock -> disassociation lock

Thread B (disassociate): disassociation lock -> mmap lock

Fix by removing disassociation lock entirely and using the pre-existing hw destroy rwsem instead. hw destroy rwsem already provides the same protection: rdma umap open() and ib uverbs mmap() both use down read trylock() before registering a new VMA, so holding hw destroy rwsem in uverbs user mmap disassociate() is sufficient to block new registrations. trylock is used in both mmap paths (not blocking down read) because mmap lock is already held on entry, and uverbs user mmap disassociate() acquires mmap lock internally — a blocking read would recreate the same deadlock.

The only caller that was not taking hw destroy rwsem for write was rdma user mmap disassociate(). Fix it to take the rwsem per-ufile while iterating under lists mutex. This is safe because ib uverbs close() releases hw destroy rwsem entirely before acquiring lists mutex, 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-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---