CVE-2025-38373

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mlx5: Fix potential deadlock in MR deregistration<br /> <br /> The issue arises when kzalloc() is invoked while holding umem_mutex or<br /> any other lock acquired under umem_mutex. This is problematic because<br /> kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke<br /> mmu_notifier_invalidate_range_start(). This function can lead to<br /> mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,<br /> resulting in a deadlock.<br /> <br /> The problematic flow:<br /> CPU0 | CPU1<br /> ---------------------------------------|------------------------------------------------<br /> mlx5_ib_dereg_mr() |<br /> → revoke_mr() |<br /> → mutex_lock(&amp;umem_odp-&gt;umem_mutex) |<br /> | mlx5_mkey_cache_init()<br /> | → mutex_lock(&amp;dev-&gt;cache.rb_lock)<br /> | → mlx5r_cache_create_ent_locked()<br /> | → kzalloc(GFP_KERNEL)<br /> | → fs_reclaim()<br /> | → mmu_notifier_invalidate_range_start()<br /> | → mlx5_ib_invalidate_range()<br /> | → mutex_lock(&amp;umem_odp-&gt;umem_mutex)<br /> → cache_ent_find_and_store() |<br /> → mutex_lock(&amp;dev-&gt;cache.rb_lock) |<br /> <br /> Additionally, when kzalloc() is called from within<br /> cache_ent_find_and_store(), we encounter the same deadlock due to<br /> re-acquisition of umem_mutex.<br /> <br /> Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()<br /> and before acquiring rb_lock. This ensures that we don&amp;#39;t hold<br /> umem_mutex while performing memory allocations that could trigger<br /> the reclaim path.<br /> <br /> This change prevents the deadlock by ensuring proper lock ordering and<br /> avoiding holding locks during memory allocation operations that could<br /> trigger the reclaim path.<br /> <br /> The following lockdep warning demonstrates the deadlock:<br /> <br /> python3/20557 is trying to acquire lock:<br /> ffff888387542128 (&amp;umem_odp-&gt;umem_mutex){+.+.}-{4:4}, at:<br /> mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]<br /> <br /> but task is already holding lock:<br /> ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:<br /> unmap_vmas+0x7b/0x1a0<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:<br /> fs_reclaim_acquire+0x60/0xd0<br /> mem_cgroup_css_alloc+0x6f/0x9b0<br /> cgroup_init_subsys+0xa4/0x240<br /> cgroup_init+0x1c8/0x510<br /> start_kernel+0x747/0x760<br /> x86_64_start_reservations+0x25/0x30<br /> x86_64_start_kernel+0x73/0x80<br /> common_startup_64+0x129/0x138<br /> <br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> fs_reclaim_acquire+0x91/0xd0<br /> __kmalloc_cache_noprof+0x4d/0x4c0<br /> mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]<br /> mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]<br /> mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]<br /> __mlx5_ib_add+0x4b/0x190 [mlx5_ib]<br /> mlx5r_probe+0xd9/0x320 [mlx5_ib]<br /> auxiliary_bus_probe+0x42/0x70<br /> really_probe+0xdb/0x360<br /> __driver_probe_device+0x8f/0x130<br /> driver_probe_device+0x1f/0xb0<br /> __driver_attach+0xd4/0x1f0<br /> bus_for_each_dev+0x79/0xd0<br /> bus_add_driver+0xf0/0x200<br /> driver_register+0x6e/0xc0<br /> __auxiliary_driver_register+0x6a/0xc0<br /> do_one_initcall+0x5e/0x390<br /> do_init_module+0x88/0x240<br /> init_module_from_file+0x85/0xc0<br /> idempotent_init_module+0x104/0x300<br /> __x64_sys_finit_module+0x68/0xc0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> -&gt; #1 (&amp;dev-&gt;cache.rb_lock){+.+.}-{4:4}:<br /> __mutex_lock+0x98/0xf10<br /> __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]<br /> mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]<br /> ib_dereg_mr_user+0x85/0x1f0 [ib_core]<br /> <br /> ---truncated---