EUVD-2025-211016
GHSA-xvmw-v642-vxxr
Severity by source
AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
Agree with vendor: VF foothold gives PR:L, register command is low-complexity, DoS crosses VF-to-host boundary (S:C, A:H), no C/I impact; AV:A retained though local access is plausible.
Primary rating from Vendor (nvidia).
CVSS VectorVendor: nvidia
Lifecycle Timeline
2DescriptionCVE.org
NVIDIA ConnectX and Bluefield contain a vulnerability in a control register, where a user with VF access could cause improper access control for the register interface by sending a malicious command to the firmware. A successful exploit of this vulnerability might lead to denial of service.
AnalysisAI
Improper access control in the firmware control-register interface of NVIDIA ConnectX (ConnectX-5 plus GA, LTS23 and LTS24 firmware branches) and BlueField (GA, LTS23, LTS24) adapters allows a user who already holds an SR-IOV virtual function (VF) on the device to send a crafted command to the firmware and disturb the register interface, producing a denial-of-service condition on the affected adapter and, per the scope-change vector, potentially on components beyond it. The issue is reachable from an adjacent network position with low complexity but requires a legitimate VF foothold (PR:L), and the impact is availability-only - no confidentiality or integrity loss is described. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and NVIDIA's own advisory is the authoritative source for fixed firmware releases. EPSS and KEV signals are absent from the supplied intelligence.
Technical ContextAI
ConnectX (including ConnectX-5) and BlueField SmartNIC/DPU adapters expose SR-IOV, in which a physical function (PF) is partitioned into virtual functions (VFs) that are passed through to guests or tenants. Each VF gets a constrained view of device resources, and the vendor firmware is expected to enforce per-VF isolation on the hardware register interface - including control registers that configure or gate access to device internals. CVE-2025-33207 is mapped to CWE-1262 (register-interface error class), which describes exactly this pattern: the register interface fails to protect hardware registers from a less-privileged user program. Here a VF-holder can issue a malicious firmware command that reaches a control register it should not be able to influence, corrupting or stalling the register interface and taking down device availability. The CVSS 3.1 vector AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H (base 6.8) is consistent with a low-complexity attack from an adjacent/link-local position using an existing low-privileged VF credential; the S:C (scope changed) component reflects that the availability impact can propagate beyond the vulnerable firmware boundary, while C:N/I:N confirms that no data disclosure or modification is expected. Exploitation is therefore most relevant in multi-tenant SR-IOV deployments where VFs are delegated to untrusted guests; single-tenant hosts that never expose VFs have a far smaller exposure surface.
RemediationAI
No vendor-released patch version is identified in the available data; NVIDIA's advisory at https://github.com/NVIDIA/product-security/tree/main/2026/5847 is the authoritative source and should be checked for the firmware build per branch (GA / LTS23 / LTS24) that resolves the control-register handling, which then needs to be applied to the adapter/DPU firmware rather than to the host OS. Until that firmware is deployed, the most effective compensating control is to stop delegating SR-IOV VFs on affected ConnectX/BlueField ports to untrusted guests or tenants - that removes the PR:L foothold entirely, at the cost of losing hardware-assisted network virtualization and forcing those workloads onto software bridges or separate physical ports. Where VFs must remain in use, restrict them to trusted guests, keep PF configuration out of tenant reach, avoid mixing tenants that require strong mutual isolation on the same physical adapter, and monitor adapter firmware and host kernel logs for repeated reset/fault events that could indicate register-interface abuse. Fully disabling SR-IOV on the port also closes the attack path but breaks VF-based passthrough workloads; similarly, restricting the fabric so that only trusted link-local peers can reach exposed VF uplinks reduces the AV:A exposure but does not fix the underlying firmware weakness. There is no indication in the supplied data of an exploited vulnerability, so a risk-based firmware rollout aligned to maintenance windows is appropriate.
More in Bluefield Ga
View allOut-of-bounds write in the command interface of NVIDIA ConnectX SmartNICs and BlueField DPUs allows a local user holding
Out-of-bounds write in the command interface of NVIDIA ConnectX network adapters and BlueField DPUs allows a local user
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today