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

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