Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Initialize obj_event-&gt;obj_sub_list before xa_insert<br /> <br /> The obj_event may be loaded immediately after inserted, then if the<br /> list_head is not initialized then we may get a poisonous pointer. This<br /> fixes the crash below:<br /> <br /> mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced)<br /> mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056<br /> mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0<br /> mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps<br /> IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060<br /> Mem abort info:<br /> ESR = 0x96000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000<br /> [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#1] SMP<br /> Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E)<br /> [last unloaded: mst_pci]<br /> CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1<br /> Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023<br /> pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--)<br /> pc : dispatch_event_fd+0x68/0x300 [mlx5_ib]<br /> lr : devx_event_notifier+0xcc/0x228 [mlx5_ib]<br /> sp : ffff80001005bcf0<br /> x29: ffff80001005bcf0 x28: 0000000000000001<br /> x27: ffff244e0740a1d8 x26: ffff244e0740a1d0<br /> x25: ffffda56beff5ae0 x24: ffffda56bf911618<br /> x23: ffff244e0596a480 x22: ffff244e0596a480<br /> x21: ffff244d8312ad90 x20: ffff244e0596a480<br /> x19: fffffffffffffff0 x18: 0000000000000000<br /> x17: 0000000000000000 x16: ffffda56be66d620<br /> x15: 0000000000000000 x14: 0000000000000000<br /> x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000040 x10: ffffda56bfcafb50<br /> x9 : ffffda5655c25f2c x8 : 0000000000000010<br /> x7 : 0000000000000000 x6 : ffff24545a2e24b8<br /> x5 : 0000000000000003 x4 : ffff80001005bd28<br /> x3 : 0000000000000000 x2 : 0000000000000000<br /> x1 : ffff244e0596a480 x0 : ffff244d8312ad90<br /> Call trace:<br /> dispatch_event_fd+0x68/0x300 [mlx5_ib]<br /> devx_event_notifier+0xcc/0x228 [mlx5_ib]<br /> atomic_notifier_call_chain+0x58/0x80<br /> mlx5_eq_async_int+0x148/0x2b0 [mlx5_core]<br /> atomic_notifier_call_chain+0x58/0x80<br /> irq_int_handler+0x20/0x30 [mlx5_core]<br /> __handle_irq_event_percpu+0x60/0x220<br /> handle_irq_event_percpu+0x3c/0x90<br /> handle_irq_event+0x58/0x158<br /> handle_fasteoi_irq+0xfc/0x188<br /> generic_handle_irq+0x34/0x48<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Fix timeline left held on VMA alloc error<br /> <br /> The following error has been reported sporadically by CI when a test<br /> unbinds the i915 driver on a ring submission platform:<br /> <br /> [239.330153] ------------[ cut here ]------------<br /> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-&gt;mm.shrink_count)<br /> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]<br /> ...<br /> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]<br /> ...<br /> [239.330942] Call Trace:<br /> [239.330944] <br /> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915]<br /> [239.331202] i915_driver_release+0x86/0xa0 [i915]<br /> [239.331482] devm_drm_dev_init_release+0x61/0x90<br /> [239.331494] devm_action_release+0x15/0x30<br /> [239.331504] release_nodes+0x3d/0x120<br /> [239.331517] devres_release_all+0x96/0xd0<br /> [239.331533] device_unbind_cleanup+0x12/0x80<br /> [239.331543] device_release_driver_internal+0x23a/0x280<br /> [239.331550] ? bus_find_device+0xa5/0xe0<br /> [239.331563] device_driver_detach+0x14/0x20<br /> ...<br /> [357.719679] ---[ end trace 0000000000000000 ]---<br /> <br /> If the test also unloads the i915 module then that&amp;#39;s followed with:<br /> <br /> [357.787478] =============================================================================<br /> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown()<br /> [357.788031] -----------------------------------------------------------------------------<br /> [357.788204] Object 0xffff888109e7f480 @offset=29824<br /> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244<br /> [357.788994] i915_vma_instance+0xee/0xc10 [i915]<br /> [357.789290] init_status_page+0x7b/0x420 [i915]<br /> [357.789532] intel_engines_init+0x1d8/0x980 [i915]<br /> [357.789772] intel_gt_init+0x175/0x450 [i915]<br /> [357.790014] i915_gem_init+0x113/0x340 [i915]<br /> [357.790281] i915_driver_probe+0x847/0xed0 [i915]<br /> [357.790504] i915_pci_probe+0xe6/0x220 [i915]<br /> ...<br /> <br /> Closer analysis of CI results history has revealed a dependency of the<br /> error on a few IGT tests, namely:<br /> - igt@api_intel_allocator@fork-simple-stress-signal,<br /> - igt@api_intel_allocator@two-level-inception-interruptible,<br /> - igt@gem_linear_blits@interruptible,<br /> - igt@prime_mmap_coherency@ioctl-errors,<br /> which invisibly trigger the issue, then exhibited with first driver unbind<br /> attempt.<br /> <br /> All of the above tests perform actions which are actively interrupted with<br /> signals. Further debugging has allowed to narrow that scope down to<br /> DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring<br /> submission, in particular.<br /> <br /> If successful then that function, or its execlists or GuC submission<br /> equivalent, is supposed to be called only once per GEM context engine,<br /> followed by raise of a flag that prevents the function from being called<br /> again. The function is expected to unwind its internal errors itself, so<br /> it may be safely called once more after it returns an error.<br /> <br /> In case of ring submission, the function first gets a reference to the<br /> engine&amp;#39;s legacy timeline and then allocates a VMA. If the VMA allocation<br /> fails, e.g. when i915_vma_instance() called from inside is interrupted<br /> with a signal, then ring_context_alloc() fails, leaving the timeline held<br /> referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the<br /> timeline is got, and only that last one is put on successful completion.<br /> As a consequence, the legacy timeline, with its underlying engine status<br /> page&amp;#39;s VMA object, is still held and not released on driver unbind.<br /> <br /> Get the legacy timeline only after successful allocation of the context<br /> engine&amp;#39;s VMA.<br /> <br /> v2: Add a note on other submission methods (Krzysztof Karas):<br /> Both execlists and GuC submission use lrc_alloc() which seems free<br /> from a similar issue.<br /> <br /> (cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> optee: ffa: fix sleep in atomic context<br /> <br /> The OP-TEE driver registers the function notif_callback() for FF-A<br /> notifications. However, this function is called in an atomic context<br /> leading to errors like this when processing asynchronous notifications:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0<br /> | preempt_count: 1, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13<br /> | Hardware name: linux,dummy-virt (DT)<br /> | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn<br /> | Call trace:<br /> | show_stack+0x18/0x24 (C)<br /> | dump_stack_lvl+0x78/0x90<br /> | dump_stack+0x18/0x24<br /> | __might_resched+0x114/0x170<br /> | __might_sleep+0x48/0x98<br /> | mutex_lock+0x24/0x80<br /> | optee_get_msg_arg+0x7c/0x21c<br /> | simple_call_with_arg+0x50/0xc0<br /> | optee_do_bottom_half+0x14/0x20<br /> | notif_callback+0x3c/0x48<br /> | handle_notif_callbacks+0x9c/0xe0<br /> | notif_get_and_handle+0x40/0x88<br /> | generic_exec_single+0x80/0xc0<br /> | smp_call_function_single+0xfc/0x1a0<br /> | notif_pcpu_irq_work_fn+0x2c/0x38<br /> | process_one_work+0x14c/0x2b4<br /> | worker_thread+0x2e4/0x3e0<br /> | kthread+0x13c/0x210<br /> | ret_from_fork+0x10/0x20<br /> <br /> Fix this by adding work queue to process the notification in a<br /> non-atomic context.