Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods<br /> <br /> drvdata::gpiods is supposed to hold an array of &amp;#39;gpio_desc&amp;#39; pointers. But<br /> the memory is allocated for only one pointer. This will lead to<br /> out-of-bounds access later in the code if &amp;#39;config::ngpios&amp;#39; is &gt; 1. So<br /> fix the code to allocate enough memory to hold &amp;#39;config::ngpios&amp;#39; of GPIO<br /> descriptors.<br /> <br /> While at it, also move the check for memory allocation failure to be below<br /> the allocation to make it more readable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix warning when reconnecting channel<br /> <br /> When reconnecting a channel in smb2_reconnect_server(), a dummy tcon<br /> is passed down to smb2_reconnect() with -&gt;query_interface<br /> uninitialized, so we can&amp;#39;t call queue_delayed_work() on it.<br /> <br /> Fix the following warning by ensuring that we&amp;#39;re queueing the delayed<br /> worker from correct tcon.<br /> <br /> WARNING: CPU: 4 PID: 1126 at kernel/workqueue.c:2498 __queue_delayed_work+0x1d2/0x200<br /> Modules linked in: cifs cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]<br /> CPU: 4 UID: 0 PID: 1126 Comm: kworker/4:0 Not tainted 6.16.0-rc3 #5 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-4.fc42 04/01/2014<br /> Workqueue: cifsiod smb2_reconnect_server [cifs]<br /> RIP: 0010:__queue_delayed_work+0x1d2/0x200<br /> Code: 41 5e 41 5f e9 7f ee ff ff 90 0f 0b 90 e9 5d ff ff ff bf 02 00<br /> 00 00 e8 6c f3 07 00 89 c3 eb bd 90 0f 0b 90 e9 57 f&gt; 0b 90 e9 65 fe<br /> ff ff 90 0f 0b 90 e9 72 fe ff ff 90 0f 0b 90 e9<br /> RSP: 0018:ffffc900014afad8 EFLAGS: 00010003<br /> RAX: 0000000000000000 RBX: ffff888124d99988 RCX: ffffffff81399cc1<br /> RDX: dffffc0000000000 RSI: ffff888114326e00 RDI: ffff888124d999f0<br /> RBP: 000000000000ea60 R08: 0000000000000001 R09: ffffed10249b3331<br /> R10: ffff888124d9998f R11: 0000000000000004 R12: 0000000000000040<br /> R13: ffff888114326e00 R14: ffff888124d999d8 R15: ffff888114939020<br /> FS: 0000000000000000(0000) GS:ffff88829f7fe000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe7a2b4038 CR3: 0000000120a6f000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> queue_delayed_work_on+0xb4/0xc0<br /> smb2_reconnect+0xb22/0xf50 [cifs]<br /> smb2_reconnect_server+0x413/0xd40 [cifs]<br /> ? __pfx_smb2_reconnect_server+0x10/0x10 [cifs]<br /> ? local_clock_noinstr+0xd/0xd0<br /> ? local_clock+0x15/0x30<br /> ? lock_release+0x29b/0x390<br /> process_one_work+0x4c5/0xa10<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __list_add_valid_or_report+0x37/0x120<br /> worker_thread+0x2f1/0x5a0<br /> ? __kthread_parkme+0xde/0x100<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1fe/0x380<br /> ? kthread+0x10f/0x380<br /> ? __pfx_kthread+0x10/0x10<br /> ? local_clock_noinstr+0xd/0xd0<br /> ? ret_from_fork+0x1b/0x1f0<br /> ? local_clock+0x15/0x30<br /> ? lock_release+0x29b/0x390<br /> ? rcu_is_watching+0x20/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x15b/0x1f0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> irq event stamp: 1116206<br /> hardirqs last enabled at (1116205): [] __up_console_sem+0x52/0x60<br /> hardirqs last disabled at (1116206): [] queue_delayed_work_on+0x6e/0xc0<br /> softirqs last enabled at (1116138): [] __smb_send_rqst+0x42d/0x950 [cifs]<br /> softirqs last disabled at (1116136): [] release_sock+0x21/0xf0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c/designware: Fix an initialization issue<br /> <br /> The i2c_dw_xfer_init() function requires msgs and msg_write_idx from the<br /> dev context to be initialized.<br /> <br /> amd_i2c_dw_xfer_quirk() inits msgs and msgs_num, but not msg_write_idx.<br /> <br /> This could allow an out of bounds access (of msgs).<br /> <br /> Initialize msg_write_idx before calling i2c_dw_xfer_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: cs40l50-vibra - fix potential NULL dereference in cs40l50_upload_owt()<br /> <br /> The cs40l50_upload_owt() function allocates memory via kmalloc()<br /> without checking for allocation failure, which could lead to a<br /> NULL pointer dereference.<br /> <br /> Return -ENOMEM in case allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix iteration of extrefs during log replay<br /> <br /> At __inode_add_ref() when processing extrefs, if we jump into the next<br /> label we have an undefined value of victim_name.len, since we haven&amp;#39;t<br /> initialized it before we did the goto. This results in an invalid memory<br /> access in the next iteration of the loop since victim_name.len was not<br /> initialized to the length of the name of the current extref.<br /> <br /> Fix this by initializing victim_name.len with the current extref&amp;#39;s name<br /> length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: fix data race in show_numa_info()<br /> <br /> The following data-race was found in show_numa_info():<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show<br /> <br /> read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0:<br /> show_numa_info mm/vmalloc.c:4936 [inline]<br /> vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016<br /> seq_read_iter+0x373/0xb40 fs/seq_file.c:230<br /> proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299<br /> ....<br /> <br /> write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1:<br /> show_numa_info mm/vmalloc.c:4934 [inline]<br /> vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016<br /> seq_read_iter+0x373/0xb40 fs/seq_file.c:230<br /> proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299<br /> ....<br /> <br /> value changed: 0x0000008f -&gt; 0x00000000<br /> ==================================================================<br /> <br /> According to this report,there is a read/write data-race because<br /> m-&gt;private is accessible to multiple CPUs. To fix this, instead of<br /> allocating the heap in proc_vmalloc_init() and passing the heap address to<br /> m-&gt;private, vmalloc_info_show() should allocate the heap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spinand: fix memory leak of ECC engine conf<br /> <br /> Memory allocated for the ECC engine conf is not released during spinand<br /> cleanup. Below kmemleak trace is seen for this memory leak:<br /> <br /> unreferenced object 0xffffff80064f00e0 (size 8):<br /> comm "swapper/0", pid 1, jiffies 4294937458<br /> hex dump (first 8 bytes):<br /> 00 00 00 00 00 00 00 00 ........<br /> backtrace (crc 0):<br /> kmemleak_alloc+0x30/0x40<br /> __kmalloc_cache_noprof+0x208/0x3c0<br /> spinand_ondie_ecc_init_ctx+0x114/0x200<br /> nand_ecc_init_ctx+0x70/0xa8<br /> nanddev_ecc_engine_init+0xec/0x27c<br /> spinand_probe+0xa2c/0x1620<br /> spi_mem_probe+0x130/0x21c<br /> spi_probe+0xf0/0x170<br /> really_probe+0x17c/0x6e8<br /> __driver_probe_device+0x17c/0x21c<br /> driver_probe_device+0x58/0x180<br /> __device_attach_driver+0x15c/0x1f8<br /> bus_for_each_drv+0xec/0x150<br /> __device_attach+0x188/0x24c<br /> device_initial_probe+0x10/0x20<br /> bus_probe_device+0x11c/0x160<br /> <br /> Fix the leak by calling nanddev_ecc_engine_cleanup() inside<br /> spinand_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect<br /> <br /> Remove redundant netif_napi_del() call from disconnect path.<br /> <br /> A WARN may be triggered in __netif_napi_del_locked() during USB device<br /> disconnect:<br /> <br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> <br /> This happens because netif_napi_del() is called in the disconnect path while<br /> NAPI is still enabled. However, it is not necessary to call netif_napi_del()<br /> explicitly, since unregister_netdev() will handle NAPI teardown automatically<br /> and safely. Removing the redundant call avoids triggering the warning.<br /> <br /> Full trace:<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV<br /> lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV<br /> lan78xx 1-1:1.0 enu1: Link is Down<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> Modules linked in: flexcan can_dev fuse<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT<br /> Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)<br /> Workqueue: usb_hub_wq hub_event<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __netif_napi_del_locked+0x2b4/0x350<br /> lr : __netif_napi_del_locked+0x7c/0x350<br /> sp : ffffffc085b673c0<br /> x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8<br /> x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb<br /> x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000<br /> x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000<br /> x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028<br /> x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8<br /> x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000<br /> x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001<br /> x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000<br /> Call trace:<br /> __netif_napi_del_locked+0x2b4/0x350 (P)<br /> lan78xx_disconnect+0xf4/0x360<br /> usb_unbind_interface+0x158/0x718<br /> device_remove+0x100/0x150<br /> device_release_driver_internal+0x308/0x478<br /> device_release_driver+0x1c/0x30<br /> bus_remove_device+0x1a8/0x368<br /> device_del+0x2e0/0x7b0<br /> usb_disable_device+0x244/0x540<br /> usb_disconnect+0x220/0x758<br /> hub_event+0x105c/0x35e0<br /> process_one_work+0x760/0x17b0<br /> worker_thread+0x768/0xce8<br /> kthread+0x3bc/0x690<br /> ret_from_fork+0x10/0x20<br /> irq event stamp: 211604<br /> hardirqs last enabled at (211603): [] _raw_spin_unlock_irqrestore+0x84/0x98<br /> hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80<br /> softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8<br /> softirqs last disabled at (210993): [] __do_softirq+0x18/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Refuse to evaluate a method if arguments are missing<br /> <br /> As reported in [1], a platform firmware update that increased the number<br /> of method parameters and forgot to update a least one of its callers,<br /> caused ACPICA to crash due to use-after-free.<br /> <br /> Since this a result of a clear AML issue that arguably cannot be fixed<br /> up by the interpreter (it cannot produce missing data out of thin air),<br /> address it by making ACPICA refuse to evaluate a method if the caller<br /> attempts to pass fewer arguments than expected to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Disable interrupts before resetting the GPU<br /> <br /> Currently, an interrupt can be triggered during a GPU reset, which can<br /> lead to GPU hangs and NULL pointer dereference in an interrupt context<br /> as shown in the following trace:<br /> <br /> [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0<br /> [ 314.043822] Mem abort info:<br /> [ 314.046606] ESR = 0x0000000096000005<br /> [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 314.055651] SET = 0, FnV = 0<br /> [ 314.058695] EA = 0, S1PTW = 0<br /> [ 314.061826] FSC = 0x05: level 1 translation fault<br /> [ 314.066694] Data abort info:<br /> [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000<br /> [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight<br /> [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1<br /> [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)<br /> [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d]<br /> [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d]<br /> [ 314.160198] sp : ffffffc080003ea0<br /> [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000<br /> [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0<br /> [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000<br /> [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000<br /> [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000<br /> [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001<br /> [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874<br /> [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180<br /> [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb<br /> [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 314.234807] Call trace:<br /> [ 314.237243] v3d_irq+0xec/0x2e0 [v3d]<br /> [ 314.240906] __handle_irq_event_percpu+0x58/0x218<br /> [ 314.245609] handle_irq_event+0x54/0xb8<br /> [ 314.249439] handle_fasteoi_irq+0xac/0x240<br /> [ 314.253527] handle_irq_desc+0x48/0x68<br /> [ 314.257269] generic_handle_domain_irq+0x24/0x38<br /> [ 314.261879] gic_handle_irq+0x48/0xd8<br /> [ 314.265533] call_on_irq_stack+0x24/0x58<br /> [ 314.269448] do_interrupt_handler+0x88/0x98<br /> [ 314.273624] el1_interrupt+0x34/0x68<br /> [ 314.277193] el1h_64_irq_handler+0x18/0x28<br /> [ 314.281281] el1h_64_irq+0x64/0x68<br /> [ 314.284673] default_idle_call+0x3c/0x168<br /> [ 314.288675] do_idle+0x1fc/0x230<br /> [ 314.291895] cpu_startup_entry+0x3c/0x50<br /> [ 314.295810] rest_init+0xe4/0xf0<br /> [ 314.299030] start_kernel+0x5e8/0x790<br /> [ 314.302684] __primary_switched+0x80/0x90<br /> [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017)<br /> [ 314.312775] ---[ end trace 0000000000000000 ]---<br /> [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> [ 314.324249] SMP: stopping secondary CPUs<br /> [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000<br /> [ 314.334076] PHYS_OFFSET: 0x0<br /> [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b<br /> [ 314.342337] Memory Limit: none<br /> [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> Before resetting the G<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling<br /> <br /> __xa_store() and __xa_erase() were used without holding the proper lock,<br /> which led to a lockdep warning due to unsafe RCU usage. This patch<br /> replaces them with xa_store() and xa_erase(), which perform the necessary<br /> locking internally.<br /> <br /> =============================<br /> WARNING: suspicious RCPU usage<br /> 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted<br /> -----------------------------<br /> ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 3 locks held by kworker/u136:0/219:<br /> at: process_one_work+0xbe4/0x15f0<br /> process_one_work+0x75c/0x15f0<br /> pagefault_mr+0x9a5/0x1390 [mlx5_ib]<br /> <br /> stack backtrace:<br /> CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted<br /> 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]<br /> Call Trace:<br /> dump_stack_lvl+0xa8/0xc0<br /> lockdep_rcu_suspicious+0x1e6/0x260<br /> xas_create+0xb8a/0xee0<br /> xas_store+0x73/0x14c0<br /> __xa_store+0x13c/0x220<br /> ? xa_store_range+0x390/0x390<br /> ? spin_bug+0x1d0/0x1d0<br /> pagefault_mr+0xcb5/0x1390 [mlx5_ib]<br /> ? _raw_spin_unlock+0x1f/0x30<br /> mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib]<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib]<br /> process_one_work+0x7db/0x15f0<br /> ? pwq_dec_nr_in_flight+0xda0/0xda0<br /> ? assign_work+0x168/0x240<br /> worker_thread+0x57d/0xcd0<br /> ? rescuer_thread+0xc40/0xc40<br /> kthread+0x3b3/0x800<br /> ? kthread_is_per_cpu+0xb0/0xb0<br /> ? lock_downgrade+0x680/0x680<br /> ? do_raw_spin_lock+0x12d/0x270<br /> ? spin_bug+0x1d0/0x1d0<br /> ? finish_task_switch.isra.0+0x284/0x9e0<br /> ? lockdep_hardirqs_on_prepare+0x284/0x400<br /> ? kthread_is_per_cpu+0xb0/0xb0<br /> ret_from_fork+0x2d/0x70<br /> ? kthread_is_per_cpu+0xb0/0xb0<br /> ret_from_fork_asm+0x11/0x20

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---