GPU VulnDB

Database/Control plane, storage & DevOps

Intel 82599 Ethernet Controllers and Adapters - network-on-chip shared-resource isolation: Improper isolation of shared

CVE-2021-33096Control plane, storage & DevOpsINTEL-SA-00571CVE-2021-33061curated

Impact

Improper isolation of shared resources inside the controller's network-on-chip lets an authenticated user cause denial of service. This is the multi-tenant failure mode that matters for SR-IOV: one function on the adapter - a virtual function assigned to a tenant VM - can exhaust or wedge a resource shared with the physical function and the other VFs. A tenant who is only supposed to control their own VF takes down networking for every other tenant sharing that adapter, and for the host. Intel documented no firmware fix for the 82599 here, which makes it a design limit of the part rather than a bug you close.

Who can reach it

An authenticated local user on any function of the adapter - concretely, a tenant VM that has been assigned an SR-IOV virtual function on a shared 82599.

What to do

Intel's guidance for the 82599 is mitigation, not a firmware fix: do not share a single adapter's virtual functions across mutually untrusted tenants. Practically that means either dedicating a physical adapter per tenant, moving multi-tenant workloads off 82599-class parts onto controllers with stronger VF isolation, or accepting the shared-fate risk and rate-limiting at the switch. If your multi-tenant story depends on SR-IOV VF isolation, this CVE is the reason to test that assumption on your actual silicon rather than reading it off a datasheet.

References

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.