NVIDIA/Mellanox ConnectX flow steering core (mlx5 fs_core rule tree linkage): Flow steering is what decides which

Impact

Flow steering is what decides which packets reach which virtual function, and therefore which tenant. add_rule_fg() only linked newly created rules into the steering tree when their refcount was 1, while create_flow_handle deliberately reuses identical existing rules - so a handle could end up holding a rule with refcount 2 that was never linked, with NULL parent and root. Deleting the flow group then dereferences NULL. Unlinked steering rules are steering state the driver has lost track of, on the structure that enforces tenant traffic separation on a shared adapter.

Who can reach it

Local. Reached by the ordinary create/delete cycle of flow steering rules - which in an SR-IOV or switchdev cluster is driven by the CNI and by tenant network policy changes, i.e. by tenant-visible actions.

What to do

Kernel update linking rules into the tree correctly regardless of refcount. No configuration workaround; flow steering cannot be turned off on an SR-IOV adapter.

References