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

CVSS 8.7CVE-2026-53230Firmware, BMC & network fabricnet/mlx5 slab-out-of-bounds in mlx5_query_nic_vport_mac_listcurated

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

https://nvd.nist.gov/vuln/detail/CVE-2026-53230 https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-53230.json

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.