https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 23 Oct 2026 18:08:54 +0000 https://db.gcve.eu/vuln/cve-2026-98431 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency</p> <p>Commit 51976c6cd786 (&#34;RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages&#34;) introduced disassociation_lock to protect new mmap registrations against uverbs_user_mmap_disassociate(), but created an ABBA deadlock:</p> <p>Thread A (mmap / fork): mmap_lock -&gt; disassociation_lock</p> <p>Thread B (disassociate): disassociation_lock -&gt; mmap_lock</p> <p>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.</p> <p>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.</p> <p>lockdep warning:</p> <p>[ 776.654252] ====================================================== [ 776…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency</p> <p>Commit 51976c6cd786 (&#34;RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages&#34;) introduced disassociation_lock to protect new mmap registrations against uverbs_user_mmap_disassociate(), but created an ABBA deadlock:</p> <p>Thread A (mmap / fork): mmap_lock -&gt; disassociation_lock</p> <p>Thread B (disassociate): disassociation_lock -&gt; mmap_lock</p> <p>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.</p> <p>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.</p> <p>lockdep warning:</p> <p>[ 776.654252] ====================================================== [ 776…</p> https://db.gcve.eu/vuln/cve-2026-98431