{"cve":"CVE-2025-38373","nvd":{"published":"2025-07-25T13:15:26.283","modified":"2026-10-30T13:18:03.610","status":"Analyzed","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix potential deadlock in MR deregistration\n\nThe issue arises when kzalloc() is invoked while holding umem_mutex or\nany other lock acquired under umem_mutex. This is problematic because\nkzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke\nmmu_notifier_invalidate_range_start(). This function can lead to\nmlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,\nresulting in a deadlock.\n\nThe problematic flow:\n             CPU0                      |              CPU1\n---------------------------------------|------------------------------------------------\nmlx5_ib_dereg_mr()                     |\n → revoke_mr()                         |\n   → mutex_lock(&umem_odp->umem_mutex) |\n                                       | mlx5_mkey_cache_init()\n                                       |  → mutex_lock(&dev->cache.rb_lock)\n                                       |  → mlx5r_cache_create_ent_locked()\n                                       |    → kzalloc(GFP_KERNEL)\n                                       |      → fs_reclaim()\n                                       |        → mmu_notifier_invalidate_range_start()\n                                       |          → mlx5_ib_invalidate_range()\n                                       |            → mutex_lock(&umem_odp->umem_mutex)\n   → cache_ent_find_and_store()        |\n     → mutex_lock(&dev->cache.rb_lock) |\n\nAdditionally, when kzalloc() is called from within\ncache_ent_find_and_store(), we encounter the same deadlock due to\nre-acquisition of umem_mutex.\n\nSolve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()\nand before acquiring rb_lock. This ensures that we don't hold\numem_mutex while performing memory allocations that could trigger\nthe reclaim path.\n\nThis change prevents the deadlock by ensuring proper lock ordering and\navoiding holding locks during memory allocation operations that could\ntrigger the reclaim path.\n\nThe following lockdep warning demonstrates the deadlock:\n\n python3/20557 is trying to acquire lock:\n ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at:\n mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]\n\n but task is already holding lock:\n ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:\n unmap_vmas+0x7b/0x1a0\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n       fs_reclaim_acquire+0x60/0xd0\n       mem_cgroup_css_alloc+0x6f/0x9b0\n       cgroup_init_subsys+0xa4/0x240\n       cgroup_init+0x1c8/0x510\n       start_kernel+0x747/0x760\n       x86_64_start_reservations+0x25/0x30\n       x86_64_start_kernel+0x73/0x80\n       common_startup_64+0x129/0x138\n\n -> #2 (fs_reclaim){+.+.}-{0:0}:\n       fs_reclaim_acquire+0x91/0xd0\n       __kmalloc_cache_noprof+0x4d/0x4c0\n       mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]\n       mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]\n       mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]\n       __mlx5_ib_add+0x4b/0x190 [mlx5_ib]\n       mlx5r_probe+0xd9/0x320 [mlx5_ib]\n       auxiliary_bus_probe+0x42/0x70\n       really_probe+0xdb/0x360\n       __driver_probe_device+0x8f/0x130\n       driver_probe_device+0x1f/0xb0\n       __driver_attach+0xd4/0x1f0\n       bus_for_each_dev+0x79/0xd0\n       bus_add_driver+0xf0/0x200\n       driver_register+0x6e/0xc0\n       __auxiliary_driver_register+0x6a/0xc0\n       do_one_initcall+0x5e/0x390\n       do_init_module+0x88/0x240\n       init_module_from_file+0x85/0xc0\n       idempotent_init_module+0x104/0x300\n       __x64_sys_finit_module+0x68/0xc0\n       do_syscall_64+0x6d/0x140\n       entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}:\n       __mutex_lock+0x98/0xf10\n       __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]\n       mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]\n       ib_dereg_mr_user+0x85/0x1f0 [ib_core]\n  \n---truncated---","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-667"],"references":["https://git.kernel.org/stable/c/2ed25aa7f7711f508b6120e336f05cd9d49943c0","https://git.kernel.org/stable/c/727eb1be65a370572edf307558ec3396b8573156","https://git.kernel.org/stable/c/beb89ada5715e7bd1518c58863eedce89ec051a7"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-30T13:47:47.119061695+00:00"},"epss":{"cve":"CVE-2025-38373","score":0.00133,"percentile":0.0284,"date":"2026-10-30"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}