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

CVSS 8.8CVE-2023-54262Firmware, BMC & network fabriccurated

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

https://git.kernel.org/stable/c/c382b693ffcb1f1ebf60d76ab9dedfe9ea13eedf https://git.kernel.org/stable/c/8fd1dac646e6b08d03e3f1ad3c5b34255b1e08e8 https://nvd.nist.gov/vuln/detail/CVE-2023-54262

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.