Linux kernel (drivers/net/ethernet/mellanox/mlx5/core): When a regular receive queue is reactivated after an AF_XDP

Impact

When a regular receive queue is reactivated after an AF_XDP socket closes, it consumes completion entries left over from the previous incarnation of the queue. Those stale descriptors point at buffers that no longer belong to the queue, which corrupts the RQ: the interface silently stops receiving for every workload on the node and then crashes on the next queue close.

Who can reach it

A local principal that can open and close AF_XDP zero-copy sockets on an mlx5 interface while traffic is flowing - a tenant container with a passed-through VF netdev and the capability to run XDP, or any host dataplane agent - can drive this by repeatedly starting and killing an XSK application. Conditional on AF_XDP zero-copy being permitted on mlx5 interfaces.

What to do

Update to a patched kernel on your stream. Interim: deny AF_XDP/XDP program attachment on mlx5 interfaces for tenant workloads (drop CAP_NET_ADMIN and CAP_BPF from those containers) until the node is rebooted onto a fixed kernel.

References