CVE-2025-38373

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: IB/mlx5: MR kaydı silme işlemindeki potansiyel deadlock düzeltildi Sorun, umem_mutex veya umem_mutex altında edinilen herhangi bir kilit tutulurken kzalloc() çağrıldığında ortaya çıkmaktadır. Bu durum sorunludur çünkü kzalloc(), karşılığında mmu_notifier_invalidate_range_start() fonksiyonunu çağırabilen fs_reclaim_aqcuire()'ı tetikleyebilir. Bu fonksiyon, tekrar umem_mutex edinmeye çalışan ve sonuç olarak deadlock ile sonuçlanan mlx5_ib_invalidate_range() fonksiyonuna yol açabilir. Sorunlu akış: 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) | Ek olarak, kzalloc() fonksiyonu cache_ent_find_and_store() içerisinden çağrıldığında, umem_mutex'in yeniden edinilmesi nedeniyle aynı deadlock ile karşılaşılmaktadır. Çözüm için, dereg_mr() içerisinde umr_revoke_mr() sonrasında ve rb_lock edinilmeden önce umem_mutex serbest bırakılmıştır. Bu, geri kazanım (reclaim) yolunu tetikleyebilecek bellek tahsisleri gerçekleştirilirken umem_mutex'in tutulmadığından emin olur. Bu değişiklik, uygun kilit sıralamasını sağlayarak ve geri kazanım yolunu tetikleyebilecek bellek tahsisi işlemleri sırasında kilitlerin tutulmasını önleyerek deadlock'u engeller. Aşağıdaki lockdep uyarısı deadlock'u göstermektedir: 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_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---