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

Impact

MULTI-TENANT ISOLATION: A tenant who has compromised their own guest kernel feeds bad input to the host GPU kernel driver and reaches code execution and privilege escalation on the host. 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. Guest root is the assumed starting point, which is exactly what every vGPU tenant has. This is the cleanest guest-to-host escape candidate in the 2024 set.

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 5586. 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