| Summary: | <app-emulation/xen-4.8.2-r3: x86 infinite loop due to missing PoD error checking (XSA-246) | ||
|---|---|---|---|
| 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.
http://xenbits.xen.org/xsa/xsa246.patch
Re-opening as this does impact amd64 hosts running x86 HVM guests with improper configurations. @maintainer, can you let us know if POD is properly configured per the XSA by default in Gentoo? 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-246 x86: infinite loop due to missing PoD error checking *** EMBARGOED UNTIL 2017-11-28 12:00 UTC *** ISSUE DESCRIPTION ================= Failure to recognize errors being returned from low level functions in Populate on Demand (PoD) code may result in higher level code entering an infinite loop. IMPACT ====== A malicious HVM guest can cause one pcpu to permanently hang. This normally cascades into the whole system freezing, resulting in a a host Denial of Service (DoS). VULNERABLE SYSTEMS ================== Xen versions from 3.4.x onwards are affected. 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 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.) CREDITS ======= This issue was discovered by Julien Grall of Linaro. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa246.patch xen-unstable xsa246-4.9.patch Xen 4.9.x, Xen 4.8.x xsa246-4.7.patch Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa246* df08a3be419f2384b495dc52c3e6ebef1eb67d8b562afe85fb6fe6a723334472 xsa246.patch b41550688e88a2a7a22349a07168f3a3ddf6fad8b3389fa27de44ae6731b6a8b xsa246-4.7.patch ea591542774c22db65dcb340120cebf58e759670b5a9fbde42ee93ed594650c8 xsa246-4.9.patch