Database/Control plane, storage & DevOps
Intel 82599 Ethernet Controllers and Adapters - network-on-chip shared-resource isolation: Improper isolation of shared
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.