CVE-2026-98431 in Linux
Riassunto
di VulDB • 15/10/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
RDMA/uverbs: Risolto il dipendenza circolare tra mmap_lock e disassociation_lock
Il commit 51976c6cd786 ("RDMA/core: Fornire rdma_user_mmap_disassociate() per dissociare le pagine mmap") ha introdotto disassociation_lock per proteggere le nuove registrazioni di mmap da uverbs_user_mmap_disassociate(), ma ha creato un deadlock ABBA:
Thread A (mmap / fork): mmap_lock -> disassociation_lock
Thread B (disassocia): disassociation_lock -> mmap_lock
Risoluzione rimuovendo completamente disassociation_lock e utilizzando hw_destroy_rwsem preesistente. hw_destroy_rwsem fornisce già la stessa protezione: rdma_umap_open() e ib_uverbs_mmap() utilizzano entrambi down_read_trylock() prima di registrare una nuova VMA, quindi mantenere hw_destroy_rwsem in uverbs_user_mmap_disassociate() è sufficiente per bloccare le nuove registrazioni. trylock viene utilizzato in entrambi i percorsi mmap (non blocca down_read) perché mmap_lock è già detenuto all'ingresso e uverbs_user_mmap_disassociate() acquisisce internamente mmap_lock — un blocco di lettura ricreerebbe lo stesso deadlock.
L'unica chiamata che non prendeva hw_destroy_rwsem per scrittura era rdma_user_mmap_disassociate(). Correggere in modo da prendere la rwsem per-ufile mentre si itera sotto lists_mutex. Questo è sicuro perché ib_uverbs_close() rilascia completamente hw_destroy_rwsem prima di acquisire lists_mutex, quindi i due lock non sono mai detenuti simultaneamente.
Avviso lockdep:
[ 776.654252] ======================================================
[ 776.655214] ATTENZIONE: possibile dipendenza circolare nel rilevamento del blocco
[ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Non contaminato (Not tainted)
[ 776.657114] ------------------------------------------------------
[ 776.658087] devlink/14824 sta cercando di acquisire il lock:
[ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs]
[ 776.660479]
[ 776.660479] ma il task sta già detenendo il lock:
[ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs]
[ 776.663177]
[ 776.663177] tale lock dipende già dal nuovo lock.
[ 776.663177]
[ 776.664525]
[ 776.664525] la catena di dipendenze esistente (in ordine inverso) è:
[ 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---
VulDB is the best source for vulnerability data and more expert information about this specific topic.