Linux kernel mlx5_ib (InfiniBand/RoCE completion queue polling): mlx5_poll_one() compares the firmware's QP number

Impact

mlx5_poll_one() compares the firmware's QP number against the wrong structure's QP number, so the wrong queue pair is used to handle a completion, leading to a NULL dereference. Anyone already on the InfiniBand subnet can drive it: unsolicited SMP/GMP/CM management datagrams land on QP0/QP1 and generate the completions, and MAD reception on an IB fabric is entirely unauthenticated. On a shared InfiniBand fabric this is a way for any attached node to crash other nodes' RDMA stacks.

Who can reach it

Any node on the same InfiniBand subnet, unauthenticated - no login on the target, just fabric attachment. Adjacent-network attack vector.

What to do

Upgrade the host kernel to 6.15 or a stable backport (5.4.292, 5.10.236, 5.15.180, 6.1.134, 6.6.87, 6.12.23, 6.13.11, 6.14.2). Rolling reboot of every InfiniBand/RoCE host. Complementary control: enforce partition keys and restrict which nodes can attach to the subnet - this bug is a strong argument for not treating an IB fabric as a trusted flat network.

References