CVE-2026-64210: Linux Kernel Race Condition Vulnerability

CVE-2026-64210 Overview

CVE-2026-64210 is a race condition vulnerability in the Linux kernel's Mellanox mlx5e network driver, specifically in the AF_XDP socket (XSK) implementation. The flaw stems from unlocked writes to the Internal Channel Operations Send Queue (ICOSQ) during NAPI polling when CPU affinity changes mid-poll. An attacker on the network can trigger conditions that lead to queue corruption and denial-of-service impact on affected systems using Mellanox network interfaces.

Critical Impact
Concurrent unlocked writes to the ICOSQ from different CPUs cause bad completion queue entries (CQEs), driver errors, and network availability loss on hosts using mlx5e with XSK zero-copy sockets.

Affected Products

Linux kernel (upstream and stable trees) using the mlx5_core / mlx5e driver
Systems with Mellanox ConnectX network adapters using AF_XDP zero-copy sockets
Distributions shipping vulnerable revisions of drivers/net/ethernet/mellanox/mlx5/core/en_rx.c

Discovery Timeline

2026-07-24 - CVE-2026-64210 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64210

Vulnerability Analysis

The vulnerability resides in the net/mlx5e driver's XSK (AF_XDP socket) fast path. During NAPI polling, the driver may need to trigger an ICOSQ interrupt on a new CPU when the queue's CPU affinity changes and XSK work remains. The interrupt trigger writes to the ICOSQ without protection, allowing concurrent producers to corrupt the queue state.

Two distinct races are documented. In the first race, mlx5e_trigger_irq() executes concurrently with mlx5e_xsk_alloc_rx_mpwqe() running on a different CPU after napi_complete_done() clears the SCHED bit and a fresh NAPI is scheduled on the new affinity CPU. In the second race, mlx5e_trigger_irq() runs against mlx5e_trigger_napi_icosq() on the same ICOSQ.

The observed symptom in production is a Bad OP in ICOSQ CQE: 0xd warning at en_rx.c:826, followed by error CQEs with vendor syndromes such as 0x68 and 0xf9, culminating in interface disruption.

Root Cause

The ICOSQ uses an optimized locking scheme that assumes single-producer semantics from the NAPI context. When affinity changes during a poll cycle, this assumption breaks: two CPUs may advance sq->pc and write WQEs concurrently. The mlx5e_icosq_sync_lock() acts as a no-op in this path, providing no serialization between the trigger and the allocation code.

Attack Vector

The issue is triggered by legitimate networking activity combined with IRQ affinity changes, but a network-adjacent attacker can amplify the race by sustaining high XSK traffic while affinity manipulations occur. Successful exploitation corrupts the ICOSQ, generates error CQEs, and can render the affected interface non-functional, producing an availability impact.

The upstream fix replaces the direct ICOSQ trigger with a kick to the async ICOSQ, which is always locked. The corrective commits are 8d3b91e7d81000d295cd914d4d9d6f860252e2bf and c326f9c68921e2f14dfcecb2f6b4216313d50248. Refer to the Kernel.org Commit Fix and the Kernel.org Commit Update for the patch details.

Detection Methods for CVE-2026-64210

Indicators of Compromise

Kernel log entries containing Bad OP in ICOSQ CQE: 0xd on interfaces backed by mlx5_core.
Error cqe on cqn messages from mlx5_core with opcode 0xd and vendor syndromes such as 0x68 or 0xf9.
WARNING traces originating from drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 in mlx5e_napi_poll.

Detection Strategies

Collect dmesg and journalctl -k output centrally and alert on mlx5_core error CQE patterns.
Monitor NIC driver counters and unexpected link resets on hosts running AF_XDP workloads.
Correlate IRQ affinity changes (/proc/irq/*/smp_affinity) with subsequent driver errors.

Monitoring Recommendations

Track kernel versions across the fleet and flag hosts running unpatched mlx5e builds with XSK enabled.
Alert on repeated NAPI poll warnings, which indicate ongoing queue corruption rather than a transient event.
Baseline normal ICOSQ CQE opcodes so opcode 0xd events surface immediately.

How to Mitigate CVE-2026-64210

Immediate Actions Required

Apply the upstream fix commits 8d3b91e7d81000d295cd914d4d9d6f860252e2bf and c326f9c68921e2f14dfcecb2f6b4216313d50248 or update to a stable kernel that includes them.
Inventory hosts running Mellanox ConnectX NICs with AF_XDP zero-copy applications and prioritize their patching.
Restart affected interfaces after patching to clear any residual corrupted queue state.

Patch Information

The fix replaces the direct call to mlx5e_trigger_irq() on the ICOSQ with a kick to the async ICOSQ, which uses full locking. Distributions and stable trees should backport both referenced commits. Consult vendor advisories for your specific kernel branch to confirm the patched revision.

Workarounds

Disable XSK zero-copy on affected interfaces until the kernel is patched.
Pin IRQ affinity for mlx5_core interrupt vectors to prevent runtime affinity changes during heavy XSK load.
Reduce or avoid dynamic IRQ balancing (for example, stop irqbalance) on hosts running AF_XDP workloads.

bash

# Configuration example: pin mlx5_core IRQs and disable irqbalance
systemctl stop irqbalance
systemctl disable irqbalance

# Pin all mlx5_core IRQs to CPU 0 to prevent affinity changes
for irq in $(grep mlx5_core /proc/interrupts | awk -F: '{print $1}'); do
    echo 1 > /proc/irq/${irq// /}/smp_affinity
done