Описание
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---
A flaw was found in the Linux kernel's Remote Direct Memory Access (RDMA) subsystem. A circular locking dependency between memory mapping locks and device disassociation locks can lead to a deadlock condition during concurrent operations. A local user could trigger this vulnerability by performing memory mapping operations while an RDMA device is being disassociated, resulting in a Denial of Service (DoS) due to a thread or system hang.
Отчет
A low impact denial-of-service flaw was found in the Linux kernel's RDMA userspace verbs (uverbs) subsystem. The commit that introduced rdma_user_mmap_disassociate() created an ABBA circular locking dependency between a process's mmap_lock and the per-file disassociation_lock: a thread performing an mmap or fork on an RDMA device file takes mmap_lock and then disassociation_lock, while a thread disassociating an RDMA device (for example during device removal or a devlink reload) takes disassociation_lock and then mmap_lock. A local user able to race memory-mapping operations on RDMA device files against RDMA device disassociation can trigger this deadlock, resulting in a kernel thread or system hang. Confidentiality and integrity are not affected. The vulnerable code is present in Red Hat Enterprise Linux 9 (from the 9.6 stream onward), Red Hat Enterprise Linux 10, Red Hat In-Vehicle OS 2, and the RHEL CoreOS 9 kernels shipped with OpenShift Container Platform 4.19 and later, because the introducing commit was backported into those streams. Earlier Red Hat Enterprise Linux 6, 7, 8, 9.2, 9.4, and 10.0 kernels and their real-time variants, and the OpenShift Container Platform 4.12 through 4.18 CoreOS images, do not contain the vulnerable code and are therefore not affected. Although the Red Hat CVSS 3.1 base score for this flaw is 5.5 (Moderate), Red Hat rates its overall impact as low, because triggering the deadlock requires winning a race between a privileged device-disassociation operation (such as a devlink reload or device unregistration, which needs administrative capabilities) and local memory-mapping activity, and the consequence is limited to availability. Fixes for the affected streams are deferred to a future planned update; the residual risk is a local denial of service restricted to systems that use RDMA hardware and run RDMA userspace workloads.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Not affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Not affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
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_lo...
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() ac
In the Linux kernel, the following vulnerability has been resolved: R ...
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()...
EPSS
5.5 Medium
CVSS3