CVE-2026-64210

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: xsk: Fix unlocked writing to ICOSQ<br /> <br /> During napi poll, when the affinity changes and there&amp;#39;s still XSK work<br /> to be done, we trigger an ICOSQ interrupt on the new CPU. However, this<br /> triggering on the ICOSQ is done unprotected.<br /> <br /> There are 2 such races:<br /> <br /> A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is<br /> running from a different CPU due to affinity change. This can happen<br /> because IRQ triggering is done after napi_complete_done(). At this point<br /> the NAPI can be scheduled on a different CPU. Like this:<br /> <br /> CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI)<br /> ------------------------------- --------------------------------<br /> napi_complete_done() clears SCHED<br /> mlx5e_cq_arm(...)<br /> napi_schedule_prep() sets SCHED<br /> mlx5e_napi_poll()<br /> mlx5e_xsk_alloc_rx_mpwqe()<br /> mlx5e_icosq_sync_lock() // noop<br /> memcpy 640 B UMR body<br /> advance sq-&gt;pc by 10<br /> mlx5e_trigger_irq(&amp;c-&gt;icosq)<br /> wqe_info[pi] = {NOP, 1}<br /> mlx5e_post_nop() advances sq-&gt;pc<br /> <br /> B) mlx5e_trigger_irq() is called on the ICOSQ when<br /> mlx5e_trigger_napi_icosq() is running.<br /> <br /> The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized<br /> locking scheme that doesn&amp;#39;t work for this scenario. Kick the async ICOSQ<br /> instead which is always locked.<br /> <br /> This issue was noticed in the wild with the following splat:<br /> <br /> netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd<br /> WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...]<br /> [...]<br /> Call Trace:<br /> <br /> mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core]<br /> __napi_poll+0x30/0x200<br /> ? skb_defer_free_flush+0x9c/0xc0<br /> net_rx_action+0x2fe/0x3f0<br /> handle_softirqs+0xd8/0x340<br /> __irq_exit_rcu+0xbc/0xe0<br /> common_interrupt+0x85/0xa0<br /> <br /> <br /> asm_common_interrupt+0x26/0x40<br /> [...]<br /> ---[ end trace 0000000000000000 ]---<br /> mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4,<br /> opcode 0xd, syndrome 0x2, vendor syndrome 0x68<br /> 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2<br /> WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64<br /> 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02<br /> 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02<br /> 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02<br /> 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02<br /> mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4,<br /> opcode 0xd, syndrome 0x5, vendor syndrome 0xf9<br /> 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2