Race Condition Affecting xen package, versions <4.13.1-r4


Severity

Recommended
0.0
high
0
10

Snyk's Security Team recommends NVD's CVSS assessment. Learn more

Threat Intelligence

EPSS
0.05% (16th 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 Learn

Learn about Race Condition vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-ALPINE316-XEN-2844896
  • published21 Jul 2020
  • disclosed7 Jul 2020

Introduced: 7 Jul 2020

CVE-2020-15567  (opens in a new tab)
CWE-362  (opens in a new tab)
CWE-269  (opens in a new tab)

How to fix?

Upgrade Alpine:3.16 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.16 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.

CVSS Scores

version 3.1