Xen on AMD-Vi - unity map handling on device reassignment: AMD-Vi unity mappings are not correctly torn down or

Impact

AMD-Vi unity mappings are not correctly torn down or re-established when a device moves between guests, so mappings from a previous owner can persist. On a GPU cloud this is the device-handoff problem in its purest form: the accelerator you just reassigned to a new tenant may still carry DMA reach into the previous tenant's memory.

Who can reach it

Requires device reassignment between guests - i.e. exactly what happens when you recycle a passed-through GPU from one customer to the next.

What to do

Fixed in Xen via XSA-400. Update the hypervisor and reboot. Operationally, treat GPU reassignment as a security transition: reset the device, verify IOMMU mappings are torn down, and prefer a host reboot between tenants where your margins allow it.

References

Related entries

• Xen on AMD-Vi - unity map handling: Second XSA-400 AMD-Vi unity-map issue. Stale or incorrect IOMMU mappings acrossCVE-2022-26359 · Xen on AMD-Vi - unity map handlingHigh
• Xen on AMD-Vi - unity map handling: Third XSA-400 AMD-Vi issue. Same class - IOMMU mappings that outlive theirCVE-2022-26360 · Xen on AMD-Vi - unity map handlingHigh
• Xen on AMD-Vi - unity map handling: Fourth XSA-400 AMD-Vi issue. Patch the set togetherCVE-2022-26361 · Xen on AMD-Vi - unity map handlingHigh
• Linux kernel (IPsec ESP): Buffer overflow in the IPsec ESP transformation code - local rootCVE-2022-27666 · Linux kernel (IPsec ESP)High
• Linux kernel (netfilter): Use-after-free write in the netfilter subsystem - privilege escalation to rootCVE-2022-32250 · Linux kernel (netfilter)High
• Linux kernel (nf_tables): Heap overflow in nft_set_elem_init() - local root, weaponised inside containersCVE-2022-34918 · Linux kernel (nf_tables)High