"value":"All Xen versions from at least 3.2 onwards are vulnerable. Earlier\nversions have not been inspected.\n\nOnly x86 systems with in-use IOMMU hardware are vulnerable. x86 systems\nwithout any IOMMUs in use are not vulnerable. On Arm systems IOMMU /\nSMMU use is not security supported.\n\nOnly x86 guests which have physical devices passed through to them can\nleverage the vulnerability."
}
]
}
}
},
"credit":{
"credit_data":{
"description":{
"description_data":[
{
"lang":"eng",
"value":"This issue was discovered by Igor Druzhinin and Andrew Cooper of Citrix,\nand further issues were uncovered by by Jan Beulich of SUSE while trying\nto fix the first issue."
}
]
}
}
},
"data_format":"MITRE",
"data_type":"CVE",
"data_version":"4.0",
"description":{
"description_data":[
{
"lang":"eng",
"value":"inappropriate x86 IOMMU timeout detection / handling\n\nIOMMUs process commands issued to them in parallel with the operation\nof the CPU(s) issuing such commands. In the current implementation in\nXen, asynchronous notification of the completion of such commands is\nnot used. Instead, the issuing CPU spin-waits for the completion of\nthe most recently issued command(s). Some of these waiting loops try\nto apply a timeout to fail overly-slow commands. The course of action\nupon a perceived timeout actually being detected is inappropriate:\n - on Intel hardware guests which did not originally cause the timeout\n may be marked as crashed,\n - on AMD hardware higher layer callers would not be notified of the\n issue, making them continue as if the IOMMU operation succeeded."
}
]
},
"impact":{
"impact_data":{
"description":{
"description_data":[
{
"lang":"eng",
"value":"A malicious guest may be able to elevate its privileges to that of the\nhost, cause host or guest Denial of Service (DoS), or cause information\nleaks."