Linux kernel (drivers/net/ethernet/mellanox/mlx5/core): A command that waits on the busy command-queue semaphore starts

Impact

A command that waits on the busy command-queue semaphore starts its firmware completion timer before it owns a slot, so forced completion handling runs against index -22 and indexes the command array out of bounds. That is an attacker-influenced negative-index access in the NIC's single control path - kernel memory corruption or a panic that takes the whole shared node's fabric with it.

Who can reach it

Requires saturating the mlx5 firmware command queue so callers block on the semaphore. A tenant container holding /dev/infiniband/uverbs* can do this by opening verbs contexts and creating RDMA objects at high rate - the reported trace is literally a CREATE_UCTX, the command issued when userspace opens a verbs context - and a VF assigned into a tenant VM has the same reach. No host root and no fabric position needed.

What to do

Boot a kernel carrying the command-semaphore timeout fix; kernel.org records it landing across the 5.5, 5.11, 5.16 and 5.17 stable branches, so take the latest point release on whichever branch you run and confirm your distro backported it. Interim controls: cap per-tenant RDMA object and context creation rates, and remove /dev/infiniband/* from containers that do not need verbs.

References