# CVE-2026-64210: net/mlx5e: xsk: Fix unlocked writing to ICOSQ

> A race condition in the Mellanox mlx5e XSK driver allows concurrent unlocked writes to the ICOSQ, potentially causing kernel warnings and denial of service.

- **Severity:** High 7.5 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 24 Jul 2026
- **Updated:** 19 Oct 2026
- **Also known as:** AZL-93342, BELL-CVE-2026-64210, DEBIAN-CVE-2026-64210, GHSA-p5xx-69g5-8564, ROOT-OS-DEBIAN-12-CVE-2026-64210, ROOT-OS-DEBIAN-13-CVE-2026-64210, ROOT-OS-UBUNTU-2204-CVE-2026-64210, UBUNTU-CVE-2026-64210

## What is CVE-2026-64210?

CVE-2026-64210 is a high-severity vulnerability in Linux kernel, published on 24 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: xsk: Fix unlocked writing to ICOSQ

During napi poll, when the affinity changes and there's still XSK work
to be done, we trigger an ICOSQ interrupt on the new CPU. However, this
triggering on the ICOSQ is done unprotected.

There are 2 such races:

A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is
running from a different CPU due to affinity change. This can happen
because IRQ triggering is done after napi_complete_done(). At this point
the NAPI can be scheduled on a different CPU. Like this:

  CPU A (old affinity, NAPI tail)    CPU B (new affinity, fresh NAPI)
  -------------------------------    --------------------------------
  napi_complete_done()  clears SCHED
  mlx5e_cq_arm(...)
                                     napi_schedule_prep() sets SCHED
                                     mlx5e_napi_poll()
                                       mlx5e_xsk_alloc_rx_mpwqe()
                                         mlx5e_icosq_sync_lock() // noop
                                         memcpy 640 B UMR body
                                         advance sq->pc by 10
  mlx5e_trigger_irq(&c->icosq)
    wqe_info[pi] = {NOP, 1}
    mlx5e_post_nop() advances sq->pc

B) mlx5e_trigger_irq() is called on the ICOSQ when
mlx5e_trigger_napi_icosq() is running.

The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized
locking scheme that doesn't work for this scenario. Kick the async ICOSQ
instead which is always locked.

This issue was noticed in the wild with the following splat:

  netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd
  WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...]
  [...]
  Call Trace:
   <IRQ>
   mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core]
   __napi_poll+0x30/0x200
   ? skb_defer_free_flush+0x9c/0xc0
   net_rx_action+0x2fe/0x3f0
   handle_softirqs+0xd8/0x340
   __irq_exit_rcu+0xbc/0xe0
   common_interrupt+0x85/0xa0
   </IRQ>
   <TASK>
   asm_common_interrupt+0x26/0x40
  [...]
  ---[ end trace 0000000000000000 ]---
  mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4,
  opcode 0xd, syndrome 0x2, vendor syndrome 0x68
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2
  WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64
  00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02
  00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02
  00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02
  00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02
  mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4,
  opcode 0xd, syndrome 0x5, vendor syndrome 0xf9
  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2

Weakness: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)

## Which versions are affected by CVE-2026-64210?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2026-64210?

Apply the vendor's patch.

## Is CVE-2026-64210 being exploited?

There is no known exploitation of CVE-2026-64210 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-64210 and fix it if it is affected.

What it is: CVE-2026-64210 is a high-severity vulnerability in Linux kernel, published on 24 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-64210 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-64210/ (Markdown: https://insights.sbomify.com/CVE-2026-64210/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-64210
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-64210
- OSV: https://osv.dev/vulnerability/CVE-2026-64210

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-64210/
Summaries are generated and may contain mistakes; the official description above is the record.