Xen AMD-Vi (AMD IOMMU) interrupt remapping table handling: On AMD-Vi platforms Xen used a single interrupt remapping

Impact

On AMD-Vi platforms Xen used a single interrupt remapping table shared between the host and every guest, and did not clear stale entries when a device was reassigned. A tenant with a passed-through device therefore programs interrupt vectors that land in other tenants' domains or in the hypervisor. This is a cross-tenant channel that exists at the level below the hypervisor's own bookkeeping - a shared hardware table doing exactly what a shared hardware table does. Impact per the advisory is denial of service against other guests, but the stale-entry half means a device reassigned from tenant A to tenant B inherits A's remapping state, which is a reuse-hygiene failure of the same family as unzeroed framebuffers.

Who can reach it

A guest with a passed-through device on an AMD-Vi host. Affects the other guests on that host, not just the attacker's own.

What to do

Apply the XSA-36 patches for the Xen 4.1/4.2 branches and reboot; per-device interrupt remapping tables are a hypervisor structural change, so there is no configuration workaround. If you are running AMD platforms with GPU passthrough on an unpatched Xen, the honest interim posture is to treat every host as single-tenant until it is patched - co-tenancy on a shared IRT is not a boundary you can compensate for at the network or scheduler layer.

References