HVM guest I/O port accesses are subject to either emulation or at least
translation. Translations are managed by the device model (via
XEN_DOMCTL_ioport_mapping), and hence the linked list used may changed
at any time. Traversal of those lists (while handling guest I/O port
accesses) therefore needs synchronizing with updates, which was missing
so far.
All Xen versions from at least 3.2 onwards are vulnerable. Earlier
versions have not been inspected.
Only x86 systems are vulnerable. Arm systems are not vulnerable.
Only entities controlling HVM guests can leverage the vulnerability.
These are device models running in either a stub domain or de-privileged
in Dom0.
Running only PV or PVH guests will avoid the vulnerability.
(Switching from a device model stub domain or a de-privileged device
model to a fully privileged Dom0 device model does NOT mitigate this
vulnerability. Rather, it simply recategorises the vulnerability to
hostile management code, regarding it "as designed"; thus it merely
reclassifies these issues as "not a bug". The security of a Xen system
using stub domains is still better than with a qemu-dm running as a Dom0
process. Users and vendors of stub qemu dm systems should not change
their configuration to use a Dom0 qemu process.)