6.2 Medium
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.9 Medium
CVSS2
Access Vector
LOCAL
Access Complexity
LOW
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
COMPLETE
AV:L/AC:L/Au:N/C:N/I:N/A:C
0.001 Low
EPSS
Percentile
33.6%
An issue was discovered in Xen 4.14.x. When moving IRQs between CPUs to
distribute the load of IRQ handling, IRQ vectors are dynamically allocated
and de-allocated on the relevant CPUs. De-allocation has to happen when
certain constraints are met. If these conditions are not met when first
checked, the checking CPU may send an interrupt to itself, in the
expectation that this IRQ will be delivered only after the condition
preventing the cleanup has cleared. For two specific IRQ vectors, this
expectation was violated, resulting in a continuous stream of
self-interrupts, which renders the CPU effectively unusable. A domain with
a passed through PCI device can cause lockup of a physical CPU, resulting
in a Denial of Service (DoS) to the entire host. Only x86 systems are
vulnerable. Arm systems are not vulnerable. Only guests with physical PCI
devices passed through to them can exploit the vulnerability.
Author | Note |
---|---|
mdeslaur | hypervisor packages are in universe. For issues in the hypervisor, add appropriate tags to each section, ex: Tags_xen: universe-binary |
6.2 Medium
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.9 Medium
CVSS2
Access Vector
LOCAL
Access Complexity
LOW
Authentication
NONE
Confidentiality Impact
NONE
Integrity Impact
NONE
Availability Impact
COMPLETE
AV:L/AC:L/Au:N/C:N/I:N/A:C
0.001 Low
EPSS
Percentile
33.6%