Linux kernel (drivers/net/ethernet/mellanox/mlx5/core/en/tc): Hardware flow-offload rules are programmed from a stale

Impact

Hardware flow-offload rules are programmed from a stale duplicate of the flow attribute, so when a neighbour update rewrites an encapsulation the driver pushes a freed object into the firmware flow-table command. The use-after-free lands in mlx5_cmd_set_fte, meaning freed kernel memory decides what steering rule the NIC installs - corrupted or attacker-influenced steering state on the device that forwards every tenant's traffic, plus node crashes.

Who can reach it

Driven by neighbour (ARP/ND) update events on the uplink, which any host on the adjacent L2 segment - including a tenant VM or container with its own IP on the fabric - can provoke by changing or churning its MAC-to-IP binding while tunnel-encapsulated TC flows are offloaded. Requires eswitch/switchdev mode with TC hardware offload and encapsulation rules in use, which is the normal configuration on a neocloud node running OVS offload.

What to do

Update to a kernel carrying the fix on your stream. Interim: disable TC hardware offload on the mlx5 uplink (ethtool -K <dev> hw-tc-offload off) or stop using tunnel-encap offload rules, and keep the fabric segment free of untrusted L2 neighbours.

References