NVIDIA vGPU software - Virtual GPU Manager (host-side vGPU plugin / nvidia.ko): MULTI-TENANT ISOLATION: A guest can

Impact

MULTI-TENANT ISOLATION: A guest can read global GPU metrics that are influenced by work running in other tenants' VMs. The attacker sits inside a tenant guest VM and the blast radius is the hypervisor host, which is running every other tenant's vGPU on the same physical GPU. This is precisely the boundary a vGPU-based multi-tenant offering is sold on. Low CVSS (2.5) and no memory corruption, but this is a genuine cross-tenant side channel: utilisation, clock and memory-pressure telemetry that moves with a neighbour's workload leaks the shape of that workload. If you sell confidential or isolated GPU capacity, this is a claim you cannot make while it is unpatched.

Who can reach it

A tenant inside their own guest VM, driving the paravirtualised vGPU control interface. Several of these need only an unprivileged process in the guest; the rest need guest root, which a tenant already has on a VM they rented. No host credentials are involved at any point.

What to do

Patch the vGPU Manager on the hypervisor host per bulletin 5670. Cost: the highest of any class here. The host driver cannot be reloaded while vGPUs are attached, so every tenant VM on that hypervisor must be live-migrated or powered off - a full host drain. NVIDIA also enforces a supported host/guest driver skew, so budget a matching guest-driver campaign in the same window or tenants lose their vGPU on next boot.

References