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 invoked while holding umemmutex or any other lock acquired under umemmutex. This is problematic because kzalloc() can trigger fsreclaimaqcuire(), which may, in turn, invoke mmunotifierinvalidaterangestart(). This function can lead to mlx5ibinvalidaterange(), which attempts to acquire umemmutex again, resulting in a deadlock.

The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5ibderegmr() | → revokemr() | → mutexlock(&umemodp->umemmutex) | | mlx5mkeycacheinit() | → mutexlock(&dev->cache.rblock) | → mlx5rcachecreateentlocked() | → kzalloc(GFPKERNEL) | → fsreclaim() | → mmunotifierinvalidaterangestart() | → mlx5ibinvalidaterange() | → mutexlock(&umemodp->umemmutex) → cacheentfindandstore() | → mutexlock(&dev->cache.rblock) |

Additionally, when kzalloc() is called from within cacheentfindandstore(), we encounter the same deadlock due to re-acquisition of umem_mutex.

Solve by releasing umemmutex in deregmr() after umrrevokemr() and before acquiring rblock. This ensures that we don't hold umemmutex 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 (&umemodp->umemmutex){+.+.}-{4:4}, at: mlx5ibinvalidaterange+0x5b/0x550 [mlx5ib]

but task is already holding lock: ffffffff82f6b840 (mmunotifierinvalidaterangestart){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (mmunotifierinvalidaterangestart){+.+.}-{0:0}: fsreclaimacquire+0x60/0xd0 memcgroupcssalloc+0x6f/0x9b0 cgroupinitsubsys+0xa4/0x240 cgroupinit+0x1c8/0x510 startkernel+0x747/0x760 x8664startreservations+0x25/0x30 x8664startkernel+0x73/0x80 commonstartup_64+0x129/0x138

-> #2 (fsreclaim){+.+.}-{0:0}: fsreclaim_acquire+0x91/0xd0 __kmalloccachenoprof+0x4d/0x4c0 mlx5rcachecreateentlocked+0x75/0x620 [mlx5ib] mlx5mkeycacheinit+0x186/0x360 [mlx5ib] mlx5ibstagepostibregumrinit+0x3c/0x60 [mlx5_ib] __mlx5ibadd+0x4b/0x190 [mlx5ib] mlx5rprobe+0xd9/0x320 [mlx5ib] auxiliarybusprobe+0x42/0x70 reallyprobe+0xdb/0x360 __driverprobedevice+0x8f/0x130 driverprobedevice+0x1f/0xb0 __driverattach+0xd4/0x1f0 busforeachdev+0x79/0xd0 busadddriver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliarydriverregister+0x6a/0xc0 dooneinitcall+0x5e/0x390 doinitmodule+0x88/0x240 initmodulefromfile+0x85/0xc0 idempotentinit_module+0x104/0x300 _x64sysfinitmodule+0x68/0xc0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53

-> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5ibderegmr+0x6f2/0x890 [mlx5ib] mlx5ibderegmr+0x21/0x110 [mlx5ib] ibderegmruser+0x85/0x1f0 [ibcore]

---truncated---