| Summary: | <app-emulation/xen-4.8.2-r3: Missing p2m error checking in PoD code (XSA-247) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Yury German <blueknight> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | dlan |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B3 [glsa+ cve] | ||
| Package list: |
app-emulation/xen-4.8.2-r3
|
Runtime testing required: | --- |
xen - x86 not stable xen-tools (x86) is stable - if Xen-tools is not affected please advise will change whiteboard to ~3 app-emulation/xen is not keyworded on x86. app-emulation/xen{,-pvgrub,-tools} are not vulnerable.
https://xenbits.xen.org/xsa/advisory-247.html
Re-opening. Xen's x86 doesn't mean Gentoo's x86. Added to an existing GLSA. This issue was resolved and addressed in GLSA 201801-14 at https://security.gentoo.org/glsa/201801-14 by GLSA coordinator Thomas Deutschmann (whissi). |
Xen Security Advisory XSA-247 Missing p2m error checking in PoD code *** EMBARGOED UNTIL 2017-11-28 12:00 UTC *** ISSUE DESCRIPTION ================= Certain actions require modification of entries in a guest's P2M (Physical-to-Machine) table. When large pages are in use for this table, such an operation may incur a memory allocation (to replace a large mapping with individual smaller ones). If this allocation fails, the p2m_set_entry() function will return an error. Unfortunately, several places in the populate-on-demand code don't check the return value of p2m_set_entry() to see if it succeeded. In some cases, the operation was meant to remove an entry from the p2m table. If this removal fails, a malicious guest may engineer that the page be returned to the Xen free list, making it available to be allocated to another domain, while it retains a writable mapping to the page. In other cases, the operation was meant to remove special populate-on-demand entries; if this removal fails, the internal accounting becomes inconsistent and may eventually hit a BUG(). The allocation involved comes from a separate pool of memory created when the domain is created; under normal operating conditions it never fails, but a malicious guest may be able to engineer situations where this pool is exhausted. IMPACT ====== An unprivileged guest can retain a writable mapping of freed memory. Depending on how this page is used, it could result in either an information leak, or full privilege escalation. Alternatively, an unprivileged guest can cause Xen to hit a BUG(), causing a clean crash - ie, host-wide denial-of-service (DoS). VULNERABLE SYSTEMS ================== All systems from Xen 3.4 are vulnerable. Only x86 systems are vulnerable. ARM is not vulnerable. x86 PV VMs cannot leverage the vulnerability. Only systems with 2MiB or 1GiB HAP pages enabled are vulnerable. The vulnerability is largely restricted to HVM guests which have been constructed in Populate-on-Demand mode (i.e. with memory < maxmem): x86 HVM domains without PoD (i.e. started with memory == maxmem, or without mentioning "maxmem" in the guest config file) also cannot leverage the vulnerability, in recent enough Xen versions: 4.8.x and later: all versions safe if PoD not configured 4.7.x: 4.7.1 and later safe if PoD not configured 4.6.x: 4.6.4 and later safe if PoD not configured 4.5.x: 4.5.4 and later safe if PoD not configured 4.4.x and earlier: all versions vulnerable even if PoD not configured The commit required to prevent this vulnerability when PoD not configured is 2a99aa99fc84a45f505f84802af56b006d14c52e xen/physmap: Do not permit a guest to populate PoD pages for itself and the corresponding backports. MITIGATION ========== Running only PV guests will avoid this issue. Running HVM guests only in non-PoD mode (maxmem == memory) will also avoid this issue. NOTE: In older releases of Xen, an HVM guest can create PoD entries itself; so this mitigation will not be effective. Specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command line will also avoid the vulnerability. Alternatively, running all x86 HVM guests in shadow mode will also avoid this vulnerability. (For example, by specifying "hap=0" in the xl domain configuration file.) RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa247/*.patch xen-unstable xsa247-4.9/*.patch Xen 4.9.x xsa247-4.8/*.patch Xen 4.8.x xsa247-4.7/*.patch Xen 4.7.x xsa247-4.6/*.patch Xen 4.6.x xsa247-4.5/*.patch Xen 4.5.x