<p>Upgrade <code>Alpine:3.15</code> <code>xen</code> to version 4.13.1-r4 or higher.</p>

Race Condition Affecting xen package, versions <4.13.1-r4

Snyk CVSS

Attack Complexity High

Scope Changed

Confidentiality High

Integrity High

Availability High

Threat Intelligence

EPSS 0.05% (14^th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk ID SNYK-ALPINE315-XEN-1928586
published 21 Jul 2020
disclosed 7 Jul 2020

Report a new vulnerability Found a mistake?

Introduced: 7 Jul 2020

CVE-2020-15567 Open this link in a new tab CWE-362 Open this link in a new tab CWE-269 Open this link in a new tab

How to fix?

Upgrade Alpine:3.15 xen to version 4.13.1-r4 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream xen package and not the xen package as distributed by Alpine. See How to fix? for Alpine:3.15 relevant fixed versions and status.

An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes. Depending on the compiler version and optimisation flags, Xen might expose a dangerous partially written PTE to the hardware, which an attacker might be able to race to exploit. A guest administrator or perhaps even an unprivileged guest user might be able to cause denial of service, data corruption, or privilege escalation. Only systems using Intel CPUs are vulnerable. Systems using AMD CPUs, and Arm systems, are not vulnerable. Only systems using nested paging (hap, aka nested paging, aka in this case Intel EPT) are vulnerable. Only HVM and PVH guests can exploit the vulnerability. The presence and scope of the vulnerability depends on the precise optimisations performed by the compiler used to build Xen. If the compiler generates (a) a single 64-bit write, or (b) a series of read-modify-write operations in the same order as the source code, the hypervisor is not vulnerable. For example, in one test build using GCC 8.3 with normal settings, the compiler generated multiple (unlocked) read-modify-write operations in source-code order, which did not constitute a vulnerability. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code-generation options). The source code clearly violates the C rules, and thus should be considered vulnerable.