Vulnerabilities

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0, prior to zebra-chain version 7.0.0, and prior to zebra-network version 6.0.0, several inbound deserialization paths in Zebra allocated buffers sized against generic transport or block-size ceilings before the tighter protocol or consensus limits were enforced. An unauthenticated or post-handshake peer could therefore force the node to preallocate and parse for orders of magnitude more data than the protocol intended, across headers messages, equihash solutions in block headers, Sapling spend vectors in V5/V4 transactions, and coinbase script bytes in blocks. This issue has been patched in zebrad version 4.4.0, zebra-chain version 7.0.0, and zebra-network version 6.0.0.

ZEBRA is a Zcash node written entirely in Rust. Prior to version 4.4.0, Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAX_BLOCK_SIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not. This issue has been patched in version 4.4.0.

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0 and prior to zebra-script version 6.0.0, the fix for CVE-2026-41583 introduced a separate issue due to insufficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes. This issue has been patched in zebrad version 4.4.0 and zebra-script version 6.0.0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: return EISDIR on nfs3_proc_create if d_alias is a dir<br /> <br /> If we found an alias through nfs3_do_create/nfs_add_or_obtain<br /> /d_splice_alias which happens to be a dir dentry, we don&amp;#39;t return<br /> any error, and simply forget about this alias, but the original<br /> dentry we were adding and passed as parameter remains negative.<br /> <br /> This later causes an oops on nfs_atomic_open_v23/finish_open since we<br /> supply a negative dentry to do_dentry_open.<br /> <br /> This has been observed running lustre-racer, where dirs and files are<br /> created/removed concurrently with the same name and O_EXCL is not<br /> used to open files (frequent file redirection).<br /> <br /> While d_splice_alias typically returns a directory alias or NULL, we<br /> explicitly check d_is_dir() to ensure that we don&amp;#39;t attempt to perform<br /> file operations (like finish_open) on a directory inode, which triggers<br /> the observed oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> unshare: fix unshare_fs() handling<br /> <br /> There&amp;#39;s an unpleasant corner case in unshare(2), when we have a<br /> CLONE_NEWNS in flags and current-&gt;fs hadn&amp;#39;t been shared at all; in that<br /> case copy_mnt_ns() gets passed current-&gt;fs instead of a private copy,<br /> which causes interesting warts in proof of correctness]<br /> <br /> &gt; I guess if private means fs-&gt;users == 1, the condition could still be true.<br /> <br /> Unfortunately, it&amp;#39;s worse than just a convoluted proof of correctness.<br /> Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS<br /> (and current-&gt;fs-&gt;users == 1).<br /> <br /> We pass current-&gt;fs to copy_mnt_ns(), all right. Suppose it succeeds and<br /> flips current-&gt;fs-&gt;{pwd,root} to corresponding locations in the new namespace.<br /> Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).<br /> We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it&amp;#39;s<br /> destroyed and its mount tree is dissolved, but... current-&gt;fs-&gt;root and<br /> current-&gt;fs-&gt;pwd are both left pointing to now detached mounts.<br /> <br /> They are pinning those, so it&amp;#39;s not a UAF, but it leaves the calling<br /> process with unshare(2) failing with -ENOMEM _and_ leaving it with<br /> pwd and root on detached isolated mounts. The last part is clearly a bug.<br /> <br /> There is other fun related to that mess (races with pivot_root(), including<br /> the one between pivot_root() and fork(), of all things), but this one<br /> is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new<br /> fs_struct even if it hadn&amp;#39;t been shared in the first place". Sure, we could<br /> go for something like "if both CLONE_NEWNS *and* one of the things that might<br /> end up failing after copy_mnt_ns() call in create_new_namespaces() are set,<br /> force allocation of new fs_struct", but let&amp;#39;s keep it simple - the cost<br /> of copy_fs_struct() is trivial.<br /> <br /> Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets<br /> a freshly allocated fs_struct, yet to be attached to anything. That<br /> seriously simplifies the analysis...<br /> <br /> FWIW, that bug had been there since the introduction of unshare(2) ;-/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Add NULL checks when resetting request and reply queues<br /> <br /> The driver encountered a crash during resource cleanup when the reply and<br /> request queues were NULL due to freed memory. This issue occurred when the<br /> creation of reply or request queues failed, and the driver freed the memory<br /> first, but attempted to mem set the content of the freed memory, leading to<br /> a system crash.<br /> <br /> Add NULL pointer checks for reply and request queues before accessing the<br /> reply/request memory during cleanup

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: init flags_valid before calling vfs_fileattr_get<br /> <br /> syzbot reported a uninit-value bug in [1].<br /> <br /> Similar to the "*get" context where the kernel&amp;#39;s internal file_kattr<br /> structure is initialized before calling vfs_fileattr_get(), we should<br /> use the same mechanism when using fa.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517<br /> fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517<br /> vfs_fileattr_get fs/file_attr.c:94 [inline]<br /> __do_sys_file_getattr fs/file_attr.c:416 [inline]<br /> <br /> Local variable fa.i created at:<br /> __do_sys_file_getattr fs/file_attr.c:380 [inline]<br /> __se_sys_file_getattr+0x8c/0xbd0 fs/file_attr.c:372

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT<br /> <br /> This resolves the follow splat and lock-up when running with PREEMPT_RT<br /> enabled on Hyper-V:<br /> <br /> [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002<br /> [ 415.140822] INFO: lockdep is turned off.<br /> [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common<br /> [ 415.140846] Preemption disabled at:<br /> [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]<br /> [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}<br /> [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024<br /> [ 415.140857] Call Trace:<br /> [ 415.140861] <br /> [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]<br /> [ 415.140863] dump_stack_lvl+0x91/0xb0<br /> [ 415.140870] __schedule_bug+0x9c/0xc0<br /> [ 415.140875] __schedule+0xdf6/0x1300<br /> [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980<br /> [ 415.140879] ? rcu_is_watching+0x12/0x60<br /> [ 415.140883] schedule_rtlock+0x21/0x40<br /> [ 415.140885] rtlock_slowlock_locked+0x502/0x1980<br /> [ 415.140891] rt_spin_lock+0x89/0x1e0<br /> [ 415.140893] hv_ringbuffer_write+0x87/0x2a0<br /> [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0<br /> [ 415.140900] ? rcu_is_watching+0x12/0x60<br /> [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]<br /> [ 415.140904] ? HARDIRQ_verbose+0x10/0x10<br /> [ 415.140908] ? __rq_qos_issue+0x28/0x40<br /> [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]<br /> [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0<br /> [ 415.140928] blk_mq_issue_direct+0x87/0x2b0<br /> [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440<br /> [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0<br /> [ 415.140935] __blk_flush_plug+0xf4/0x150<br /> [ 415.140940] __submit_bio+0x2b2/0x5c0<br /> [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360<br /> [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360<br /> [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]<br /> [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]<br /> [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]<br /> [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]<br /> [ 415.141060] generic_perform_write+0x14e/0x2c0<br /> [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]<br /> [ 415.141083] vfs_write+0x2ca/0x570<br /> [ 415.141087] ksys_write+0x76/0xf0<br /> [ 415.141089] do_syscall_64+0x99/0x1490<br /> [ 415.141093] ? rcu_is_watching+0x12/0x60<br /> [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0<br /> [ 415.141097] ? rcu_is_watching+0x12/0x60<br /> [ 415.141098] ? lock_release+0x1f0/0x2a0<br /> [ 415.141100] ? rcu_is_watching+0x12/0x60<br /> [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0<br /> [ 415.141103] ? rcu_is_watching+0x12/0x60<br /> [ 415.141104] ? __schedule+0xb34/0x1300<br /> [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170<br /> [ 415.141109] ? do_nanosleep+0x8b/0x160<br /> [ 415.141111] ? hrtimer_nanosleep+0x89/0x100<br /> [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10<br /> [ 415.141116] ? xfd_validate_state+0x26/0x90<br /> [ 415.141118] ? rcu_is_watching+0x12/0x60<br /> [ 415.141120] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141121] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141123] ? rcu_is_watching+0x12/0x60<br /> [ 415.141124] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141125] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141127] ? irqentry_exit+0x140/0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix possible NULL pointer dereference in ufshcd_add_command_trace()<br /> <br /> The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL<br /> pointer dereference when accessing hwq-&gt;id. This can happen if<br /> ufshcd_mcq_req_to_hwq() returns NULL.<br /> <br /> This patch adds a NULL check for hwq before accessing its id field to<br /> prevent a kernel crash.<br /> <br /> Kernel log excerpt:<br /> [] notify_die+0x4c/0x8c<br /> [] __die+0x60/0xb0<br /> [] die+0x4c/0xe0<br /> [] die_kernel_fault+0x74/0x88<br /> [] __do_kernel_fault+0x314/0x318<br /> [] do_page_fault+0xa4/0x5f8<br /> [] do_translation_fault+0x34/0x54<br /> [] do_mem_abort+0x50/0xa8<br /> [] el1_abort+0x3c/0x64<br /> [] el1h_64_sync_handler+0x44/0xcc<br /> [] el1h_64_sync+0x80/0x88<br /> [] ufshcd_add_command_trace+0x23c/0x320<br /> [] ufshcd_compl_one_cqe+0xa4/0x404<br /> [] ufshcd_mcq_poll_cqe_lock+0xac/0x104<br /> [] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod]<br /> [] __handle_irq_event_percpu+0xc8/0x348<br /> [] handle_irq_event+0x3c/0xa8<br /> [] handle_fasteoi_irq+0xf8/0x294<br /> [] generic_handle_domain_irq+0x54/0x80<br /> [] gic_handle_irq+0x1d4/0x330<br /> [] call_on_irq_stack+0x44/0x68<br /> [] do_interrupt_handler+0x78/0xd8<br /> [] el1_interrupt+0x48/0xa8<br /> [] el1h_64_irq_handler+0x14/0x24<br /> [] el1h_64_irq+0x80/0x88<br /> [] arch_local_irq_enable+0x4/0x1c<br /> [] cpuidle_enter+0x34/0x54<br /> [] do_idle+0x1dc/0x2f8<br /> [] cpu_startup_entry+0x30/0x3c<br /> [] secondary_start_kernel+0x134/0x1ac<br /> [] __secondary_switched+0xc4/0xcc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery<br /> <br /> In case of a TX error CQE, a recovery flow is triggered,<br /> mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,<br /> desyncing the DMA FIFO producer and consumer.<br /> <br /> After recovery, the producer pushes new DMA entries at the old<br /> dma_fifo_pc, while the consumer reads from position 0.<br /> This causes us to unmap stale DMA addresses from before the recovery.<br /> <br /> The DMA FIFO is a purely software construct with no HW counterpart.<br /> At the point of reset, all WQEs have been flushed so dma_fifo_cc is<br /> already equal to dma_fifo_pc. There is no need to reset either counter,<br /> similar to how skb_fifo pc/cc are untouched.<br /> <br /> Remove the &amp;#39;dma_fifo_cc = 0&amp;#39; reset.<br /> <br /> This fixes the following WARNING:<br /> WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90<br /> Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables]<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:iommu_dma_unmap_page+0x79/0x90<br /> Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00<br /> Call Trace:<br /> <br /> ? __warn+0x7d/0x110<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> ? report_bug+0x16d/0x180<br /> ? handle_bug+0x4f/0x90<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> ? iommu_dma_unmap_page+0x2e/0x90<br /> dma_unmap_page_attrs+0x10d/0x1b0<br /> mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core]<br /> mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core]<br /> mlx5e_napi_poll+0x8b/0xac0 [mlx5_core]<br /> __napi_poll+0x24/0x190<br /> net_rx_action+0x32a/0x3b0<br /> ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core]<br /> ? notifier_call_chain+0x35/0xa0<br /> handle_softirqs+0xc9/0x270<br /> irq_exit_rcu+0x71/0xd0<br /> common_interrupt+0x7f/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix crash when moving to switchdev mode<br /> <br /> When moving to switchdev mode when the device doesn&amp;#39;t support IPsec,<br /> we try to clean up the IPsec resources anyway which causes the crash<br /> below, fix that by correctly checking for IPsec support before trying<br /> to clean up its resources.<br /> <br /> [27642.515799] WARNING: arch/x86/mm/fault.c:1276 at<br /> do_user_addr_fault+0x18a/0x680, CPU#4: devlink/6490<br /> [27642.517159] Modules linked in: xt_conntrack xt_MASQUERADE<br /> ip6table_nat ip6table_filter ip6_tables iptable_nat nf_nat xt_addrtype<br /> rpcsec_gss_krb5 auth_rpcgss oid_registry overlay mlx5_fwctl nfnetlink<br /> zram zsmalloc mlx5_ib fuse rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi<br /> scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_core<br /> ib_core<br /> [27642.521358] CPU: 4 UID: 0 PID: 6490 Comm: devlink Not tainted<br /> 6.19.0-rc5_for_upstream_min_debug_2026_01_14_16_47 #1 NONE<br /> [27642.522923] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [27642.524528] RIP: 0010:do_user_addr_fault+0x18a/0x680<br /> [27642.525362] Code: ff 0f 84 75 03 00 00 48 89 ee 4c 89 e7 e8 5e b9 22<br /> 00 49 89 c0 48 85 c0 0f 84 a8 02 00 00 f7 c3 60 80 00 00 74 22 31 c9 eb<br /> ae 0b 48 83 c4 10 48 89 ea 48 89 de 4c 89 f7 5b 5d 41 5c 41 5d<br /> 41<br /> [27642.528166] RSP: 0018:ffff88810770f6b8 EFLAGS: 00010046<br /> [27642.529038] RAX: 0000000000000000 RBX: 0000000000000002 RCX:<br /> ffff88810b980f00<br /> [27642.530158] RDX: 00000000000000a0 RSI: 0000000000000002 RDI:<br /> ffff88810770f728<br /> [27642.531270] RBP: 00000000000000a0 R08: 0000000000000000 R09:<br /> 0000000000000000<br /> [27642.532383] R10: 0000000000000000 R11: 0000000000000000 R12:<br /> ffff888103f3c4c0<br /> [27642.533499] R13: 0000000000000000 R14: ffff88810770f728 R15:<br /> 0000000000000000<br /> [27642.534614] FS: 00007f197c741740(0000) GS:ffff88856a94c000(0000)<br /> knlGS:0000000000000000<br /> [27642.535915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [27642.536858] CR2: 00000000000000a0 CR3: 000000011334c003 CR4:<br /> 0000000000172eb0<br /> [27642.537982] Call Trace:<br /> [27642.538466] <br /> [27642.538907] exc_page_fault+0x76/0x140<br /> [27642.539583] asm_exc_page_fault+0x22/0x30<br /> [27642.540282] RIP: 0010:_raw_spin_lock_irqsave+0x10/0x30<br /> [27642.541134] Code: 07 85 c0 75 11 ba ff 00 00 00 f0 0f b1 17 75 06 b8<br /> 01 00 00 00 c3 31 c0 c3 90 0f 1f 44 00 00 53 9c 5b fa 31 c0 ba 01 00 00<br /> 00 0f b1 17 75 05 48 89 d8 5b c3 89 c6 e8 7e 02 00 00 48 89 d8<br /> 5b<br /> [27642.543936] RSP: 0018:ffff88810770f7d8 EFLAGS: 00010046<br /> [27642.544803] RAX: 0000000000000000 RBX: 0000000000000202 RCX:<br /> ffff888113ad96d8<br /> [27642.545916] RDX: 0000000000000001 RSI: ffff88810770f818 RDI:<br /> 00000000000000a0<br /> [27642.547027] RBP: 0000000000000098 R08: 0000000000000400 R09:<br /> ffff88810b980f00<br /> [27642.548140] R10: 0000000000000001 R11: ffff888101845a80 R12:<br /> 00000000000000a8<br /> [27642.549263] R13: ffffffffa02a9060 R14: 00000000000000a0 R15:<br /> ffff8881130d8a40<br /> [27642.550379] complete_all+0x20/0x90<br /> [27642.551010] mlx5e_ipsec_disable_events+0xb6/0xf0 [mlx5_core]<br /> [27642.552022] mlx5e_nic_disable+0x12d/0x220 [mlx5_core]<br /> [27642.552929] mlx5e_detach_netdev+0x66/0xf0 [mlx5_core]<br /> [27642.553822] mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core]<br /> [27642.554821] mlx5e_vport_rep_load+0x419/0x590 [mlx5_core]<br /> [27642.555757] ? xa_load+0x53/0x90<br /> [27642.556361] __esw_offloads_load_rep+0x54/0x70 [mlx5_core]<br /> [27642.557328] mlx5_esw_offloads_rep_load+0x45/0xd0 [mlx5_core]<br /> [27642.558320] esw_offloads_enable+0xb4b/0xc90 [mlx5_core]<br /> [27642.559247] mlx5_eswitch_enable_locked+0x34e/0x4f0 [mlx5_core]<br /> [27642.560257] ? mlx5_rescan_drivers_locked+0x222/0x2d0 [mlx5_core]<br /> [27642.561284] mlx5_devlink_eswitch_mode_set+0x5ac/0x9c0 [mlx5_core]<br /> [27642.562334] ? devlink_rate_set_ops_supported+0x21/0x3a0<br /> [27642.563220] devlink_nl_eswitch_set_doit+0x67/0xe0<br /> [27642.564026] genl_family_rcv_msg_doit+0xe0/0x130<br /> [27642.564816] genl_rcv_msg+0x183/0x290<br /> [27642.565466] ? __devlink_nl_pre_doit.isra.0+0x160/0x160<br /> [27642.566329] ? d<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix deadlock between devlink lock and esw-&gt;wq<br /> <br /> esw-&gt;work_queue executes esw_functions_changed_event_handler -&gt;<br /> esw_vfs_changed_event_handler and acquires the devlink lock.<br /> <br /> .eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -&gt;<br /> mlx5_devlink_eswitch_mode_set -&gt; mlx5_eswitch_disable_locked -&gt;<br /> mlx5_eswitch_event_handler_unregister -&gt; flush_workqueue deadlocks<br /> when esw_vfs_changed_event_handler executes.<br /> <br /> Fix that by no longer flushing the work to avoid the deadlock, and using<br /> a generation counter to keep track of work relevance. This avoids an old<br /> handler manipulating an esw that has undergone one or more mode changes:<br /> - the counter is incremented in mlx5_eswitch_event_handler_unregister.<br /> - the counter is read and passed to the ephemeral mlx5_host_work struct.<br /> - the work handler takes the devlink lock and bails out if the current<br /> generation is different than the one it was scheduled to operate on.<br /> - mlx5_eswitch_cleanup does the final draining before destroying the wq.<br /> <br /> No longer flushing the workqueue has the side effect of maybe no longer<br /> cancelling pending vport_change_handler work items, but that&amp;#39;s ok since<br /> those are disabled elsewhere:<br /> - mlx5_eswitch_disable_locked disables the vport eq notifier.<br /> - mlx5_esw_vport_disable disarms the HW EQ notification and marks<br /> vport-&gt;enabled under state_lock to false to prevent pending vport<br /> handler from doing anything.<br /> - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events<br /> are disabled/finished.