cbcvebase.
CVE-2025-38373
published 2025-07-25

CVE-2025-38373: In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix potential deadlock in MR deregistration The issue arises when kzalloc() is…

PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.11%
1.5th percentile
In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix potential deadlock in MR deregistration The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock. The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) | Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex. Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path. This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path. The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invali

Affected

23 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.37-1 (forky)linux 6.12.37-1 (forky)
linuxlinux
linuxlinux
linuxlinux>= 6.12.14 < 6.12.376.12.37
linuxlinux>= 6.13.3 < 6.146.14
linuxlinux>= abb604a1a9c87255c7a6f3b784410a9707baf467 < 727eb1be65a370572edf307558ec3396b8573156727eb1be65a370572edf307558ec3396b8573156
linuxlinux>= abb604a1a9c87255c7a6f3b784410a9707baf467 < 2ed25aa7f7711f508b6120e336f05cd9d49943c02ed25aa7f7711f508b6120e336f05cd9d49943c0
linuxlinux>= b13d32786acabf70a7b04ed24b7468fc3c82977c < beb89ada5715e7bd1518c58863eedce89ec051a7beb89ada5715e7bd1518c58863eedce89ec051a7
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.12.37-16.12.37-1
linuxlinux_kernel>= 0 < 6.12.37-16.12.37-1
linuxlinux_kernel>= 0 < 6.8.0-100.1006.8.0-100.100
linuxlinux_kernel>= 6.12.14 < 6.12.376.12.37
linuxlinux_kernel>= 6.13.3 < 6.15.66.15.6
ubuntulinux-aws
ubuntulinux-aws-6.8
ubuntulinux-gkeop
ubuntulinux-nvidia
ubuntulinux-nvidia-6.8
ubuntulinux-oracle
ubuntulinux-oracle-6.8
ubuntulinux-raspi-realtime
ubuntulinux-realtime

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.6MEDIUM
vendor_ubuntu5.6MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.