Linux kernel (drivers/net/ethernet/mellanox/mlx5/core): Adding a TC flower rule while the device is in NIC mode makes

Impact

Adding a TC flower rule while the device is in NIC mode makes the driver draw from an eswitch object-mapping pool that was never initialised, and the freed/uninitialised object is then fed to mlx5_add_flow_rules. KASAN reports a slab use-after-free inside the flow-steering rule-insertion path - the shared table that decides where every tenant's packets go - with a crash of the node as the visible outcome.

Who can reach it

Triggered by a tc filter add on an mlx5 netdev when the eswitch is not enabled. Any principal that can program TC offload on an mlx5 interface reaches it: the host network agent, or a tenant container/VM that was given a VF netdev plus CAP_NET_ADMIN in its own netns. It does not require a tenant RDMA or VFIO device node.

What to do

Update to a patched kernel on your stream. Interim: do not grant CAP_NET_ADMIN over an mlx5 netdev to tenant workloads, and disable hw-tc-offload on mlx5 interfaces running in NIC (non-switchdev) mode.

References