Linux kernel (drivers/net/ethernet/mellanox/mlx5/core): Two CPUs write to the internal control send queue without

CVSS 7.5CVE-2026-64210Firmware, BMC & network fabriccurated

Impact

Two CPUs write to the internal control send queue without holding a lock, so one overwrites the other's work-queue entries and advances the producer index over them. The queue that feeds receive-buffer posting ends up with garbage descriptors ('Bad OP in ICOSQ CQE'), which stalls receive on that channel and takes packet reception away from every workload sharing the interface.

Who can reach it

Racy path is in NAPI poll, so sustained receive load plus an interrupt-affinity change is enough to hit it - a busy fabric peer supplies the load. Conditional on AF_XDP zero-copy being active on the mlx5 interface, which puts the XSK UMR posting path and the IRQ-trigger path on the same queue. No tenant device node needed; it is host-shared driver state.

What to do

Update to a kernel carrying the fix on your stream. Interim: stop running AF_XDP zero-copy sockets on mlx5 interfaces, and pin IRQ affinity so channels do not migrate between CPUs under load.

References

https://git.kernel.org/stable/c/8d3b91e7d81000d295cd914d4d9d6f860252e2bf https://git.kernel.org/stable/c/c326f9c68921e2f14dfcecb2f6b4216313d50248 https://nvd.nist.gov/vuln/detail/CVE-2026-64210

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.