NVIDIA ConnectX and BlueField: a VF holder can wedge the adapter through a control register command

CVSS 6.8CVE-2025-33207Firmware, BMC & network fabriccurated

Impact

A tenant holding an SR-IOV virtual function on a ConnectX NIC or BlueField DPU can send a malicious command to the firmware and reach a control register it should not be able to touch, causing denial of service. The CVSS vector is scope-changed, so the damage is not confined to the VF that issued it: on a GPU node where VFs are handed to different pods or VMs, one tenant can take the adapter - and with it the RoCE/InfiniBand path the whole node uses for collectives - out from under its neighbours. Losing the fabric NIC on a training node stalls every rank in the job and forces a drain of a machine that is expensive to take out of service. NVIDIA rates it 6.8 with no confidentiality or integrity loss, so this is an availability and noisy-neighbour problem, not a data-exposure one.

Who can reach it

Adjacent network / local fabric: an authenticated tenant that has been given a VF on the adapter (a GPU pod or VM with SR-IOV networking). No host privilege on the hypervisor is needed.

What to do

Update the ConnectX or BlueField firmware to the fixed level listed in NVIDIA bulletin 2026/5847 for your branch (GA, LTS23 or LTS24; ConnectX-5 is also listed). Adapter firmware flashing requires the node out of service - the NIC must be reset or the host rebooted for the new image to take effect - so plan it with the node drained. Until then, the exposure only exists where VFs are handed to untrusted tenants; keeping SR-IOV VFs inside a single trust domain removes the attack path.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-33207 https://github.com/NVIDIA/product-security/tree/main/2026/5847 https://www.cve.org/CVERecord?id=CVE-2025-33207

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.