CVE-2026-64210

What it actually does

This is a race condition in the Linux kernel mlx5 Ethernet driver path for AF_XDP/XSK receive processing. During NAPI polling, if interrupt or queue affinity changes while XSK work remains pending, code can post work to the ICOSQ send queue without the locking required to serialize concurrent queue updates. Concurrent modification of ICOSQ work queue entries and producer counters can corrupt queue state, produce invalid completion queue entries, trigger kernel warnings, and disrupt the mlx5 network device. The primary technical impact is availability loss through NIC/driver malfunction, packet processing failure, or kernel instability; there is no indication from the provided data that the flaw enables data disclosure or privilege escalation.

Why it matters to the business

Systems using Linux with Mellanox/NVIDIA mlx5 Ethernet adapters and AF_XDP/XSK high-performance packet processing may experience network outages, degraded packet processing, driver errors, or host instability. For organizations relying on these adapters for virtualization, storage networking, packet capture, load balancing, DPDK/AF_XDP workloads, or high-throughput services, exploitation or accidental triggering could cause service disruption. The issue is not listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, but the CVSS availability impact is high and the bug was observed in the wild as a kernel warning/driver error condition.

How an attack unfolds

An attacker would need to cause the vulnerable mlx5 receive path to process traffic while AF_XDP/XSK work is active and CPU or interrupt affinity changes create overlapping NAPI execution on different CPUs. In a plausible remote denial-of-service scenario, the attacker sends traffic patterns that keep receive queues busy, increasing the chance that XSK allocation work and ICOSQ interrupt triggering overlap. When the race occurs, one CPU may be copying and advancing ICOSQ work queue state while another posts a NOP/interrupt trigger without proper synchronization. This can produce malformed or unexpected ICOSQ entries, resulting in mlx5 completion errors such as “Bad OP in ICOSQ CQE,” kernel warnings in the mlx5 receive path, and possible NIC queue disruption or host networking instability. Exploitation is timing-dependent and environmental, and is most relevant to systems using mlx5 hardware with AF_XDP/XSK and dynamic queue/CPU affinity behavior.

How to fix it

Apply a Linux kernel update that includes the mlx5e fix for this race, which changes the affected path to kick the async ICOSQ that is consistently locked rather than writing to the ICOSQ unprotected. Because no fixed versions were provided in the input, track the fix through the kernel vendor, distribution security advisories, or upstream stable kernel releases for the relevant supported kernel branches. Prioritize hosts with Mellanox/NVIDIA ConnectX/mlx5 adapters, AF_XDP/XSK workloads, high-throughput packet processing, or production dependency on those NICs. If immediate patching is not possible, reduce exposure by disabling or limiting AF_XDP/XSK workloads where feasible, avoiding unnecessary IRQ/NAPI affinity changes during high traffic, keeping NIC firmware and mlx5 driver packages current, and using redundancy/failover to reduce the operational impact of a NIC or host networking failure.

How to confirm the fix worked

Confirm that the running kernel includes the vendor or upstream stable patch for the mlx5e XSK ICOSQ locking race. Validate by checking the installed kernel version against distribution advisories and by reviewing kernel changelogs for the mlx5e fix described as “xsk: Fix unlocked writing to ICOSQ.” On systems with mlx5 hardware, verify that mlx5_core is loaded and inspect whether AF_XDP/XSK workloads are in use. After patching, monitor kernel logs during high receive traffic and any planned IRQ/NAPI affinity changes; the fix is effective if mlx5 ICOSQ errors and kernel warnings associated with the vulnerable path no longer recur. Also confirm that network interfaces remain stable under representative packet-processing load.

Typical attack path

1. Identify an internet-facing or reachable Linux system using Mellanox/NVIDIA mlx5 networking hardware and workloads that use AF_XDP/XSK.
2. Send sustained or carefully timed network traffic to keep mlx5 receive queues and XSK processing active.
3. Create or wait for conditions where NAPI or interrupt affinity changes while XSK work remains pending.
4. Trigger the race between ICOSQ interrupt posting and concurrent XSK receive work allocation on another CPU.
5. Cause ICOSQ queue corruption or invalid completion handling, leading to mlx5 driver warnings, network queue errors, degraded networking, or denial of service.

How to detect it

Look for evidence of prior triggering in kernel logs, system journals, crash dumps, and network monitoring telemetry from Linux hosts using mlx5_core. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, kernel crash reports, and hardware/NIC health telemetry. Search for mlx5_core errors involving ICOSQ, bad CQE operations, WQE dumps, mlx5e_napi_poll warnings, and netdevice-specific “Bad OP in ICOSQ CQE” messages. Correlate findings with periods of high ingress traffic, AF_XDP/XSK application activity, interrupt or CPU affinity changes, NIC queue resets, interface flaps, packet drops, or service availability incidents. The provided information does not include actor-specific indicators, exploit payloads, source addresses, files, or persistence artifacts; detection is therefore based on kernel/driver error artifacts and operational anomalies rather than malware-style IOCs.

• Bad OP in ICOSQ CQE
• mlx5_core
• mlx5e_napi_poll
• drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826
• Error cqe on cqn
• WQE DUMP: WQ size
• vendor syndrome 0x68
• vendor syndrome 0xf9
• opcode 0xd
• syndrome 0x2
• syndrome 0x5
• netdevice: ge-0-0-1: Bad OP in ICOSQ CQE
• mlx5_core 0000:08:00.0
• mlx5e_xsk_alloc_rx_mpwqe
• mlx5e_trigger_irq
• mlx5e_trigger_napi_icosq

What your security team should do

• Inventory Linux systems using mlx5_core or Mellanox/NVIDIA ConnectX adapters and identify which also use AF_XDP/XSK or high-throughput packet processing.
• Prioritize patching for production systems where mlx5 NIC disruption would affect customer-facing services, storage, virtualization, packet capture, load balancers, or network security tooling.
• Track distribution-specific kernel advisories and upgrade to a kernel containing the mlx5e ICOSQ race fix as soon as available.
• Until patched, avoid unnecessary CPU, IRQ, or receive-queue affinity changes on affected high-traffic systems where operationally feasible.
• Monitor kernel logs for mlx5_core ICOSQ/CQE errors, NAPI poll warnings, and network interface resets or packet loss symptoms.
• Ensure affected services have network redundancy, alternate paths, or failover capacity in case a vulnerable NIC queue or host networking stack becomes unstable.
• Because there is no KEV listing and EPSS is low, treat this as a targeted availability and reliability risk rather than an active mass-exploitation emergency, unless local telemetry shows matching mlx5 errors.