Linux kernel mlx5_core eswitch / vport (SR-IOV): Mlx5_core sizes a firmware command buffer from the physical function's

Impact

Mlx5_core sizes a firmware command buffer from the physical function's MAC-list capability, but a virtual function can be configured with a larger max. Querying that VF makes the firmware response overflow the PF's buffer - a slab out-of-bounds in the host kernel driven by a value the VF side controls. CVSS scope is Changed. This is the clean VF-to-PF memory-safety break: a tenant holding an SR-IOV VF corrupts host kernel memory belonging to the NIC that serves everyone on the node.

Who can reach it

A tenant or container with local control of an mlx5 SR-IOV VF, in combination with a VF max-MAC-list setting larger than the PF's capability. Triggered from the PF-side eswitch worker, so no host root is needed on the attacker side.

What to do

Upgrade the host kernel to 7.1 or a stable backport (6.6.143, 6.12.94, 6.18.36, 7.0.13). Rolling reboot of every SR-IOV host - drain GPU jobs per node, this is not live-patchable in practice. Interim: audit devlink VF MAC-list max settings and keep them at or below the PF capability.

References