Skip to content

GitLab

aports
aports
Closed
Opened by Alicha CH@alichaReporter
Report abuse New issue

[3.3] xen: Multiple security issues (xsa-154 - xsa-170)

(CVE-2016-2270, xsa-154) x86: inconsistent cachability flags on guest mappings

Multiple mappings of the same physical page with different cachability
setting can cause problems. While one category (risk of using stale
data) affects only guests themselves (and hence avoiding this can be
left for them to control), the other category being Machine Check
exceptions can be fatal to entire hosts.

References:

http://xenbits.xen.org/xsa/advisory-154.html

(CVE-2015-8550, xsa-155) paravirtualized drivers incautious about shared memory contents

The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.

References:

http://xenbits.xen.org/xsa/advisory-155.html

(CVE-2015-5307, CVE-2015-8104, xsa-156) x86: CPU lockup during exception delivery

When a benign exception occurs while delivering another benign
exception, it is architecturally specified that these would be
delivered sequentially. There are, however, cases where this results in
an infinite loop inside the CPU, which (in the virtualized case) can be
broken only by intercepting delivery of the respective exception.

Architecturally, at least some of these cases should also be
resolvable by an arriving NMI or external interrupt, but empirically
this has been determined to not be the case.

References:

http://xenbits.xen.org/xsa/advisory-156.html

(CVE-2015-8551, CVE-2015-8552, xsa-157) Linux pciback missing sanity checks leading to crash

Xen PCI backend driver does not perform proper sanity checks on the
device’s state.

Which in turn allows the generic MSI code (called by Xen PCI backend) to be
called incorrectly leading to hitting BUG conditions or causing NULL pointer
exceptions in the MSI code. (CVE-2015-8551)

To exploit this the guest can craft specific sequence of XEN_PCI_OP_*
operations which will trigger this.

Furthermore the frontend can also craft an continous stream of
XEN_PCI_OP_enable_msi which will trigger an continous
stream of WARN() messages triggered by the MSI code leading to the logging
in the initial domain to exhaust disk space. (CVE-2015-8552)

References:

http://xenbits.xen.org/xsa/advisory-157.html

(CVE-2015-8339, CVE-2015-8340, xsa-159) XENMEM_exchange error handling issues

Error handling in the operation may involve handing back pages to
the domain. This operation may fail when in parallel the domain gets
torn down. So far this failure unconditionally resulted in the host
being brought down due to an internal error being assumed. This is
CVE-2015-8339.

Furthermore error handling so far wrongly included the release of a
lock. That lock, however, was either not acquired or already released
on all paths leading to the error handling sequence. This is
CVE-2015-8340.

References:

http://xenbits.xen.org/xsa/advisory-159.html

(CVE-2015-8341, xsa – 160) libxl leak of pv kernel and initrd on error

When constructing a guest which is configured to use a PV bootloader
which runs as a userspace process in the toolstack domain
(e.g. pygrub) libxl creates a mapping of the files to be used as
kernel and initial ramdisk when building the guest domain.

References:

http://xenbits.xen.org/xsa/advisory-160.html

(CVE-2015-7504, xsa-162) heap buffer overflow vulnerability in pcnet emulator

The AMD PC-Net II emulator(hw/net/pcnet.c), while receiving
packets in loopback mode, appends CRC code to the receive buffer.
If the data size given is same as the buffer size(4096), the appended CRC code overwrites 4 bytes after the s->buffer,
making the adjacent ‘s->irq’ object point to a new location.

References:

http://xenbits.xen.org/xsa/advisory-162.html

(CVE-2015-8554, XSA-164) qemu-dm buffer overrun in MSI-X handling

“qemu-xen-traditional” (aka qemu-dm) tracks state for each MSI-X table
entry of a passed through device. This is used/updated on
(intercepted) accesses to the page(s) containing the MSI-X table.

References:

http://xenbits.xen.org/xsa/advisory-164.html

(CVE-2015-8555, XSA-165) information leak in legacy x86 FPU/XMM initialization

When XSAVE/XRSTOR are not in use by Xen to manage guest extended
register state, the initial values in the FPU stack and XMM registers
seen by the guest upon first use are those left there by the previous
user of those registers.

References:

http://xenbits.xen.org/xsa/advisory-165.html

(CVE-2016-1570, XSA-167) PV superpage functionality missing sanity checks

The PV superpage functionality lacks certain validity checks on data
being passed to the hypervisor by guests. This is the case for the
page identifier (MFN) passed to MMUEXT_MARK_SUPER and
MMUEXT_UNMARK_SUPER sub-ops of the HYPERVISOR_mmuext_op hypercall as
well as for various forms of page table updates.

References:

http://xenbits.xen.org/xsa/advisory-167.html

(CVE-2016-1571, XSA 168) VMX: intercept issue with INVLPG on non-canonical address

While INVLPG does not cause a General Protection Fault when used on a
non-canonical address, INVVPID in its “individual address” variant,
which is used to back the intercepted INVLPG in certain cases, fails in
such cases. Failure of INVVPID results in a hypervisor bug check.

References:

http://xenbits.xen.org/xsa/advisory-168.html

(CVE-2015-8615, XSA-169) x86: unintentional logging upon guest changing callback method

HYPERVISOR_hvm_op sub-op HVMOP_set_param’s HVM_PARAM_CALLBACK_IRQ
operation intends to log the new callback method in debug builds only.
The full message, however, is split into two parts, the second one of
which didn’t get suppressed on non-debug builds as would have been
intended.

References:

http://xenbits.xen.org/xsa/advisory-169.html

(CVE-2016-2271, XSA-170) VMX: guest user mode may crash guest with non-canonical RIP

VMX refuses attempts to enter a guest with an instruction pointer which
doesn’t satisfy certain requirements. In particular, the instruction
pointer needs to be canonical when entering a guest currently in 64-bit
mode. This is the case even if the VM entry information specifies an
exception to be injected immediately (in which case the bad instruction
pointer would possibly never get used for other than pushing onto the
exception handler’s stack). Provided the guest OS allows user mode to
map the virtual memory space immediately below the canonical/non-
canonical address boundary, a non-canonical instruction pointer can
result even from normal user mode execution. VM entry failure, however,
is fatal to the guest.

References:

http://xenbits.xen.org/xsa/advisory-170.html

(from redmine: issue id 5160, created on 2016-02-22, closed on 2016-03-01)

main/xen: security fix multiple vulnerabilties. Fixes #5160

(CVE-2016-2270, XSA-154)
(CVE-2015-8550, XSA-155)
(CVE-2015-8339, CVE-2015-8340, XSA-159)
(CVE-2015-8341, XSA-160)
(CVE-2015-8555, XSA-165)
(CVE-2016-1570, XSA-167)
(CVE-2016-1571, XSA 168)
(CVE-2015-8615, XSA-169)
(CVE-2016-2271, XSA-170)

(cherry picked from commit ccba2d08cc9d7de25cfa2eccbe943cb2e4ced400)
  • Revision 7e224e4a on 2016-02-24T10:12:35Z:
main/qemu: security fix (CVE-2015-8550, xsa-155). Fixes #5160

(cherry picked from commit 561bee69490ba198a8875f13eeba68964043ad1d)
  • Revision 5de48aa6 on 2016-02-24T12:56:13Z:
main/linux-grsec: security fix (CVE-2015-8550, xsa-155). Fixes #5160

(cherry picked from commit ed9dc5651926188f0fe277a0e5a51961ee5545f1)
  • Revision f4daf7f7 on 2016-02-25T13:43:53Z:
main/linux-grsec: security fix (CVE-2015-8551, CVE-2015-8552, XSA-157). Fixes #5160

(cherry picked from commit 1ab17fee115046c3923d9b2abeb1ff2677caaf76)
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information