Intel VT-d interrupt remapping engine as used by Xen 3.3.x-4.3.x: Proof that interrupt remapping is not a complete

CVSS 6.0CVE-2013-3495Kernel, userspace & hypervisorXSA-59curated

Impact

Proof that interrupt remapping is not a complete containment boundary. A malformed MSI emitted by a bus-mastering device the tenant controls provokes a System Error Reporting NMI, and the NMI is delivered natively - it goes around the VT-d IR engine rather than through it - panicking the host. Every tenant on that node loses their work. The reason this belongs in a modern catalogue is architectural rather than historical: operators reason about passthrough safety as 'IOMMU plus IR equals isolated', and this is the canonical counterexample showing that error-reporting paths in the platform bypass the remapping engine entirely.

Who can reach it

A guest with a passed-through, bus-mastering-capable PCI device on an Intel VT-d host. Attack is on the host and therefore on every co-tenant.

What to do

Apply XSA-59 and reboot the hypervisor. Note the advisory's own framing - part of the mitigation is platform configuration of SERR/NMI handling, not just hypervisor code, so the fix needs to be validated per server model rather than assumed fleet-wide. For a GPU rental fleet the pragmatic control is to make host NMI-triggered panics a monitored, attributable event: if you cannot prevent a tenant from crashing the node, you should at least be able to tell which tenant did it and stop selling to them.

References

https://xenbits.xen.org/xsa/advisory-59.html https://nvd.nist.gov/vuln/detail/CVE-2013-3495

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.