CVE-2026-98431 in Linux
Zusammenfassung
von VulDB • 14.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
RDMA/uverbs: Behebung der zyklischen Abhängigkeit zwischen mmap_lock und disassociation_lock
Das Commit 51976c6cd786 („RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") führte die disassociation_lock ein, um neue mmap-Registrierungen vor uverbs_user_mmap_disassociate() zu schützen, verursachte jedoch eine ABBA-Deadlock-Situation:
Thread A (mmap / fork): mmap_lock -> disassociation_lock
Thread B (disassociate): disassociation_lock -> mmap_lock
Behebung durch vollständiges Entfernen der disassociation_lock und stattdessen Verwendung des vorhandenen hw_destroy_rwsem. Der hw_destroy_rwsem bietet bereits den gleichen Schutz: rdma_umap_open() und ib_uverbs_mmap() verwenden beide down_read_trylock(), bevor eine neue VMA registriert wird, sodass das Halten von hw_destroy_rwsem in uverbs_user_mmap_disassociate() ausreicht, um neue Registrierungen zu blockieren. trylock wird in beiden mmap-Pfaden verwendet (nicht-blockierendes down_read), da mmap_lock beim Eintritt bereits gehalten wird und uverbs_user_mmap_disassociate() intern mmap_lock erwirbt – ein blockierender Lesezugriff würde denselben Deadlock erneut erzeugen.
Der einzige Aufrufer, der hw_destroy_rwsem nicht für Schreibzugriffe nutzte, war rdma_user_mmap_disassociate(). Dies wurde behoben, indem die rwsem pro-ufile während der Iteration unter lists_mutex erworben wird. Dies ist sicher, da ib_uverbs_close() hw_destroy_rwsem vollständig freigibt, bevor es lists_mutex erwirbt, sodass beide Sperren niemals gleichzeitig gehalten werden.
lockdep-Warnung:
[ 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---
Once again VulDB remains the best source for vulnerability data.