Linux kernel (drivers/net/ethernet/mellanox/mlx5/core/en): After a transmit-queue error triggers driver recovery, the

Impact

After a transmit-queue error triggers driver recovery, the software DMA FIFO's producer and consumer indices are left out of sync, so the driver unmaps DMA addresses recorded before the recovery. The node tears down IOMMU mappings that no longer correspond to the buffers being freed - stale-mapping teardown on a shared NIC, which means either a live mapping is revoked underneath in-flight DMA or a dead IOVA is left mapped, on top of repeated queue failures.

Who can reach it

Reachable over the network: the recovery path is entered on a transmit error completion, which a peer on the Ethernet/RDMA fabric can provoke through congestion, malformed or oversized traffic, and link-level abuse against the node's uplink. No tenant device node is required - the corrupted state is in the host's shared TX path, so any tenant sharing that NIC is exposed.

What to do

Update to a kernel carrying the fix on your stream. There is no useful runtime workaround: the code runs whenever an error CQE occurs on a TX queue. Reduce exposure by rate-limiting or isolating untrusted senders on the fabric until nodes are rebooted onto a fixed kernel.

References