UBUNTU-CVE-2026-98431: Low severity ubuntu/linux-hwe-edge vulnerability

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---