Lucene search

K
xenXen ProjectXSA-300
HistoryJul 09, 2019 - 1:54 p.m.

Linux: No grant table and foreign mapping limits

2019-07-0913:54:00
Xen Project
xenbits.xen.org
114

6.5 Medium

CVSS3

Attack Vector

LOCAL

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

CHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/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.0004 Low

EPSS

Percentile

13.3%

ISSUE DESCRIPTION

Virtual device backends and device models running in domain 0, or other backend driver domains, need to be able to map guest memory (either via grant mappings, or via the foreign mapping interface).
Inside Xen, mapped grants are tracked by the maptrack structure. The size of this structure is chosen during domain creation, and has a fixed upper bound for the lifetime of the domain.
For Linux to keep track of these mappings, it needs to have a page structure for each one. In practice the number of page structures is usually limited. In PV guests, a range of pfns are typically set aside at boot (“pre-ballooned”) for this purpose. For HVM/PVH and Arm guests, no memory is set aside to begin with. In either case, when more of this “foreign / grant map pfn space” is needed, Linux will balloon out extra pages to use for this purpose.
Unfortunately, in Linux, there are no limits, either on the total amount of memory which the domain will attempt to balloon out, nor on the amount of “foreign / grant map” memory which any individual guest can consume.
For Linux userspace backends (e.g. QEMU) which use /dev/xen/gnttab or /proc/xen/gnttab, there is an arbitrary mapping limit which, if hit, will prevent further mappings from being established.
As a result, a malicious guest may be able to, with crafted requests, cause a backend Linux domain to either:

  1. Fill the maptrack table in Xen and/or hit the userspace limit. This will starve I/O from other guests served by the same backend.
  2. Balloon out sufficient RAM to cause it to swap excessively, or run completely out of memory. This may starve all operations from the domain, including I/O from other guests, or may cause a crash of the domain.

IMPACT

Guest may be able to crash backend Linux domains, or starve operations inside the domain, including the processing of guest I/O requests (Guest Denial-of-Service).
If the backend is domain 0, which is the most common configuration, then host-wide operations may be starved, or the host may crash (Host Denial-of-Service).

VULNERABLE SYSTEMS

All versions of Linux are vulnerable. Only Linux guests acting as backend domains for other guests may be exploited.
All Arm domains are vulnerable, as are x86 PVH/HVM guests. The vulnerability of x86 PV guests depends on how they were configured at boot.

6.5 Medium

CVSS3

Attack Vector

LOCAL

Attack Complexity

LOW

Privileges Required

LOW

User Interaction

NONE

Scope

CHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/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.0004 Low

EPSS

Percentile

13.3%