VuXML ID | Description |
da70d472-af59-11e7-ace2-f8b156b439c5 | xen-kernel -- multiple vulnerabilities
The Xen project reports multiple vulnerabilities.
Discovery 2017-10-12 Entry 2017-10-12 xen-kernel
< 4.7.2_6
http://xenbits.xen.org/xsa/advisory-237.html
http://xenbits.xen.org/xsa/advisory-238.html
http://xenbits.xen.org/xsa/advisory-239.html
http://xenbits.xen.org/xsa/advisory-240.html
http://xenbits.xen.org/xsa/advisory-241.html
http://xenbits.xen.org/xsa/advisory-242.html
http://xenbits.xen.org/xsa/advisory-243.html
http://xenbits.xen.org/xsa/advisory-244.html
|
04cf89e3-5854-11e6-b334-002590263bf5 | xen-kernel -- x86: Missing SMAP whitelisting in 32-bit exception / event delivery
The Xen Project reports:
Supervisor Mode Access Prevention is a hardware feature designed
to make an Operating System more robust, by raising a pagefault
rather than accidentally following a pointer into userspace.
However, legitimate accesses into userspace require whitelisting,
and the exception delivery mechanism for 32bit PV guests wasn't
whitelisted.
A malicious 32-bit PV guest kernel can trigger a safety check,
crashing the hypervisor and causing a denial of service to other
VMs on the host.
Discovery 2016-07-26 Entry 2016-08-02 xen-kernel
gt 4.5 lt 4.7.0_3
CVE-2016-6259
ports/211482
http://xenbits.xen.org/xsa/advisory-183.html
|
e839ca04-b40d-11e5-9728-002590263bf5 | xen-kernel -- information leak in legacy x86 FPU/XMM initialization
The Xen Project reports:
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.
A malicious domain may be able to leverage this to obtain sensitive
information such as cryptographic keys from another domain.
Discovery 2015-12-17 Entry 2016-01-06 xen-kernel
< 4.5.2_1
CVE-2015-8555
ports/205841
http://xenbits.xen.org/xsa/advisory-165.html
|
90becf7c-1acf-11e7-970f-002590263bf5 | xen-kernel -- broken check in memory_exchange() permits PV guest breakout
The Xen Project reports:
The XSA-29 fix introduced an insufficient check on XENMEM_exchange
input, allowing the caller to drive hypervisor memory accesses
outside of the guest provided input/output arrays.
A malicious or buggy 64-bit PV guest may be able to access all of
system memory, allowing for all of privilege escalation, host
crashes, and information leaks.
Discovery 2017-04-04 Entry 2017-04-06 xen-kernel
< 4.7.2_1
CVE-2017-7228
https://xenbits.xen.org/xsa/advisory-212.html
|
032aa524-5854-11e6-b334-002590263bf5 | xen-kernel -- x86: Privilege escalation in PV guests
The Xen Project reports:
The PV pagetable code has fast-paths for making updates to
pre-existing pagetable entries, to skip expensive re-validation
in safe cases (e.g. clearing only Access/Dirty bits). The bits
considered safe were too broad, and not actually safe.
A malicious PV guest administrator can escalate their privilege to
that of the host.
Discovery 2016-07-26 Entry 2016-08-02 xen-kernel
< 4.7.0_3
CVE-2016-6258
ports/211482
http://xenbits.xen.org/xsa/advisory-182.html
|
3ae078ca-c7eb-11e6-ae1b-002590263bf5 | xen-kernel -- x86 PV guests may be able to mask interrupts
The Xen Project reports:
Certain PV guest kernel operations (page table writes in
particular) need emulation, and use Xen's general x86 instruction
emulator. This allows a malicious guest kernel which asynchronously
modifies its instruction stream to effect the clearing of EFLAGS.IF
from the state used to return to guest context.
A malicious guest kernel administrator can cause a host hang or
crash, resulting in a Denial of Service.
Discovery 2016-12-21 Entry 2016-12-22 xen-kernel
< 4.7.1_3
CVE-2016-10024
https://xenbits.xen.org/xsa/advisory-202.html
|
3d9f6260-881d-11e5-ab94-002590263bf5 | xen-kernel -- Uncontrolled creation of large page mappings by PV guests
The Xen Project reports:
The code to validate level 2 page table entries is bypassed when
certain conditions are satisfied. This means that a PV guest can
create writable mappings using super page mappings. Such writable
mappings can violate Xen intended invariants for pages which Xen is
supposed to keep read-only. This is possible even if the
"allowsuperpage" command line option is not used.
Malicious PV guest administrators can escalate privilege so as to
control the whole system.
Discovery 2015-10-29 Entry 2015-11-11 xen-kernel
ge 3.4 lt 4.5.1_1
CVE-2015-7835
http://xenbits.xen.org/xsa/advisory-148.html
|
942433db-c661-11e6-ae1b-002590263bf5 | xen-kernel -- x86: Mishandling of SYSCALL singlestep during emulation
The Xen Project reports:
The typical behaviour of singlestepping exceptions is determined at
the start of the instruction, with a #DB trap being raised at the
end of the instruction. SYSCALL (and SYSRET, although we don't
implement it) behave differently because the typical behaviour
allows userspace to escalate its privilege. (This difference in
behaviour seems to be undocumented.) Xen wrongly raised the
exception based on the flags at the start of the instruction.
Guest userspace which can invoke the instruction emulator can use
this flaw to escalate its privilege to that of the guest kernel.
Discovery 2016-12-19 Entry 2016-12-20 xen-kernel
< 4.7.1_2
CVE-2016-10013
http://xenbits.xen.org/xsa/advisory-204.html
|
fc1f8795-881d-11e5-ab94-002590263bf5 | xen-kernel -- leak of main per-domain vcpu pointer array
The Xen Project reports:
A domain's primary array of vcpu pointers can be allocated by a
toolstack exactly once in the lifetime of a domain via the
XEN_DOMCTL_max_vcpus hypercall. This array is leaked on domain
teardown. This memory leak could -- over time -- exhaust the host's
memory.
A domain given partial management control via XEN_DOMCTL_max_vcpus
can mount a denial of service attack affecting the whole system. The
ability to also restart or create suitable domains is also required
to fully exploit the issue. Without this the leak is limited to a
small multiple of the maximum number of vcpus for the domain. The
maximum leak is 64kbytes per domain (re)boot (less on ARM).
Discovery 2015-10-29 Entry 2015-11-11 xen-kernel
< 4.5.1_1
CVE-2015-7969
http://xenbits.xen.org/xsa/advisory-149.html
|
e43b210a-4212-11e6-942d-bc5ff45d0f28 | xen-kernel -- x86 software guest page walk PS bit handling flaw
The Xen Project reports:
The Page Size (PS) page table entry bit exists at all page table
levels other than L1. Its meaning is reserved in L4, and
conditionally reserved in L3 and L2 (depending on hardware
capabilities). The software page table walker in the hypervisor,
however, so far ignored that bit in L4 and (on respective hardware)
L3 entries, resulting in pages to be treated as page tables which
the guest OS may not have designated as such. If the page in
question is writable by an unprivileged user, then that user will
be able to map arbitrary guest memory.
On vulnerable OSes, guest user mode code may be able to establish
mappings of arbitrary memory inside the guest, allowing it to
elevate its privileges inside the guest.
Discovery 2016-05-17 Entry 2016-07-04 xen-kernel
< 4.7.0
CVE-2016-4480
http://xenbits.xen.org/xsa/advisory-176.html
|
4aae54be-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- x86 HVM: Overflow of sh_ctxt->seg_reg[]
The Xen Project reports:
x86 HVM guests running with shadow paging use a subset of the x86
emulator to handle the guest writing to its own pagetables. There
are situations a guest can provoke which result in exceeding the
space allocated for internal state.
A malicious HVM guest administrator can cause Xen to fail a bug
check, causing a denial of service to the host.
Discovery 2016-09-08 Entry 2016-12-04 xen-kernel
< 4.7.1
CVE-2016-7094
ports/214936
https://xenbits.xen.org/xsa/advisory-187.html
|
83350009-881e-11e5-ab94-002590263bf5 | xen-kernel -- Long latency populate-on-demand operation is not preemptible
The Xen Project reports:
When running an HVM domain in Populate-on-Demand mode, Xen would
sometimes search the domain for memory to reclaim, in response to
demands for population of other pages in the same domain. This
search runs without preemption. The guest can, by suitable
arrangement of its memory contents, create a situation where this
search is a time-consuming linear scan of the guest's address
space.
A malicious HVM guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant
period.
Discovery 2015-10-29 Entry 2015-11-11 xen-kernel
ge 3.4 lt 4.5.1_1
CVE-2015-7970
http://xenbits.xen.org/xsa/advisory-150.html
|
d51ced72-4212-11e6-942d-bc5ff45d0f28 | xen-kernel -- x86 shadow pagetables: address width overflow
The Xen Project reports:
In the x86 shadow pagetable code, the guest frame number of a
superpage mapping is stored in a 32-bit field. If a shadowed guest
can cause a superpage mapping of a guest-physical address at or
above 2^44 to be shadowed, the top bits of the address will be lost,
causing an assertion failure or NULL dereference later on, in code
that removes the shadow.
A HVM guest using shadow pagetables can cause the host to crash.
A PV guest using shadow pagetables (i.e. being migrated) with PV
superpages enabled (which is not the default) can crash the host, or
corrupt hypervisor memory, and so a privilege escalation cannot be
ruled out.
Discovery 2016-04-18 Entry 2016-07-04 xen-kernel
ge 3.4 lt 4.7.0
CVE-2016-3960
http://xenbits.xen.org/xsa/advisory-173.html
|
80a897a2-c1a6-11e6-ae1b-002590263bf5 | xen-kernel -- x86 CMPXCHG8B emulation fails to ignore operand size override
The Xen Project reports:
The x86 instruction CMPXCHG8B is supposed to ignore legacy operand
size overrides; it only honors the REX.W override (making it
CMPXCHG16B). So, the operand size is always 8 or 16. When support
for CMPXCHG16B emulation was added to the instruction emulator,
this restriction on the set of possible operand sizes was relied on
in some parts of the emulation; but a wrong, fully general, operand
size value was used for other parts of the emulation. As a result,
if a guest uses a supposedly-ignored operand size prefix, a small
amount of hypervisor stack data is leaked to the guests: a 96 bit
leak to guests running in 64-bit mode; or, a 32 bit leak to other
guests.
A malicious unprivileged guest may be able to obtain sensitive
information from the host.
Discovery 2016-12-13 Entry 2016-12-14 xen-kernel
< 4.7.1_1
CVE-2016-9932
http://xenbits.xen.org/xsa/advisory-200.html
|
81f9d6a4-ddaf-11e5-b2bd-002590263bf5 | xen-kernel -- VMX: guest user mode may crash guest with non-canonical RIP
The Xen Project reports:
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.
Malicious HVM guest user mode code may be able to crash the
guest.
Discovery 2016-02-17 Entry 2016-02-28 xen-kernel
< 4.5.2_2
CVE-2016-2271
http://xenbits.xen.org/xsa/advisory-170.html
|
4d7cf654-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- CR0.TS and CR0.EM not always honored for x86 HVM guests
The Xen Project reports:
Instructions touching FPU, MMX, or XMM registers are required to
raise a Device Not Available Exception (#NM) when either CR0.EM or
CR0.TS are set. (Their AVX or AVX-512 extensions would consider only
CR0.TS.) While during normal operation this is ensured by the
hardware, if a guest modifies instructions while the hypervisor is
preparing to emulate them, the #NM delivery could be missed.
Guest code in one task may thus (unintentionally or maliciously)
read or modify register state belonging to another task in the same
VM.
A malicious unprivileged guest user may be able to obtain or
corrupt sensitive information (including cryptographic material) in
other programs in the same guest.
Discovery 2016-10-04 Entry 2016-12-04 xen-kernel
< 4.7.1
CVE-2016-7777
ports/214936
https://xenbits.xen.org/xsa/advisory-190.html
|
e3792855-881f-11e5-ab94-002590263bf5 | xen-kernel -- leak of per-domain profiling-related vcpu pointer array
The Xen Project reports:
A domain's xenoprofile state contains an array of per-vcpu
information... This array is leaked on domain teardown. This memory
leak could -- over time -- exhaust the host's memory.
The following parties can mount a denial of service attack
affecting the whole system:
- A malicious guest administrator via XENOPROF_get_buffer.
- A domain given suitable privilege over another domain via
XENOPROF_set_passive (this would usually be a domain being
used to profile another domain, eg with the xenoprof tool).
The ability to also restart or create suitable domains is also
required to fully exploit the issue. Without this the leak is
limited to a small multiple of the maximum number of vcpus for the
domain.
Discovery 2015-10-29 Entry 2015-11-11 xen-kernel
ge 4.0 lt 4.5.1_1
CVE-2015-7969
http://xenbits.xen.org/xsa/advisory-151.html
|
e4848ca4-8820-11e5-ab94-002590263bf5 | xen-kernel -- some pmu and profiling hypercalls log without rate limiting
The Xen Project reports:
HYPERCALL_xenoprof_op and HYPERVISOR_xenpmu_op log some errors and
attempts at invalid operations. These log messages are not
rate-limited, even though they can be triggered by guests.
A malicious guest could cause repeated logging to the hypervisor
console, leading to a Denial of Service attack.
Discovery 2015-10-29 Entry 2015-11-11 xen-kernel
ge 3.2 lt 4.5.1_1
CVE-2015-7971
http://xenbits.xen.org/xsa/advisory-152.html
|
56f0f11e-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- x86 64-bit bit test instruction emulation broken
The Xen Project reports:
The x86 instructions BT, BTC, BTR, and BTS, when used with a
destination memory operand and a source register rather than an
immediate operand, access a memory location offset from that
specified by the memory operand as specified by the high bits of
the register source.
A malicious guest can modify arbitrary memory, allowing for
arbitrary code execution (and therefore privilege escalation
affecting the whole host), a crash of the host (leading to a DoS),
or information leaks. The vulnerability is sometimes exploitable
by unprivileged guest user processes.
Discovery 2016-11-22 Entry 2016-12-04 xen-kernel
< 4.7.1
CVE-2016-9383
ports/214936
https://xenbits.xen.org/xsa/advisory-195.html
|
80adc394-ddaf-11e5-b2bd-002590263bf5 | xen-kernel -- VMX: intercept issue with INVLPG on non-canonical address
The Xen Project reports:
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.
A malicious guest can crash the host, leading to a Denial of
Service.
Discovery 2016-01-20 Entry 2016-02-28 xen-kernel
ge 3.3 lt 4.5.2_2
CVE-2016-1571
http://xenbits.xen.org/xsa/advisory-168.html
|
50ac2e96-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- x86 null segments not always treated as unusable
The Xen Project reports:
The Xen x86 emulator erroneously failed to consider the unusability
of segments when performing memory accesses.
The intended behaviour is as follows: The user data segment (%ds,
%es, %fs and %gs) selectors may be NULL in 32-bit to prevent access.
In 64-bit, NULL has a special meaning for user segments, and there
is no way of preventing access. However, in both 32-bit and 64-bit,
a NULL LDT system segment is intended to prevent access.
On Intel hardware, loading a NULL selector zeros the base as well
as most attributes, but sets the limit field to its largest possible
value. On AMD hardware, loading a NULL selector zeros the attributes,
leaving the stale base and limit intact.
Xen may erroneously permit the access using unexpected base/limit
values.
Ability to exploit this vulnerability on Intel is easy, but on AMD
depends in a complicated way on how the guest kernel manages LDTs.
An unprivileged guest user program may be able to elevate its
privilege to that of the guest operating system.
Discovery 2016-11-22 Entry 2016-12-04 xen-kernel
< 4.7.1
CVE-2016-9386
ports/214936
https://xenbits.xen.org/xsa/advisory-191.html
|
7ed7c36f-ddaf-11e5-b2bd-002590263bf5 | xen-kernel -- PV superpage functionality missing sanity checks
The Xen Project reports:
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.
Use of the feature, which is disabled by default, may have unknown
effects, ranging from information leaks through Denial of Service to
privilege escalation.
Discovery 2016-01-20 Entry 2016-02-28 xen-kernel
eq 3.4.0
eq 3.4.1
ge 4.1 lt 4.5.2_2
CVE-2016-1570
http://xenbits.xen.org/xsa/advisory-167.html
|
2cabfbab-8bfb-11e5-bd18-002590263bf5 | xen-kernel -- CPU lockup during exception delivery
The Xen Project reports:
A malicious HVM guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant,
perhaps indefinite period. If a host watchdog (Xen or dom0) is in
use, this can lead to a watchdog timeout and consequently a reboot
of the host. If another, innocent, guest, is configured with a
watchdog, this issue can lead to a reboot of such a guest.
Discovery 2015-11-10 Entry 2015-11-16 xen-kernel
< 4.5.2
CVE-2015-5307
CVE-2015-8104
http://xenbits.xen.org/xsa/advisory-156.html
|
45ca25b5-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- x86: Disallow L3 recursive pagetable for 32-bit PV guests
The Xen Project reports:
On real hardware, a 32-bit PAE guest must leave the USER and RW bit
clear in L3 pagetable entries, but the pagetable walk behaves as if
they were set. (The L3 entries are cached in processor registers,
and don't actually form part of the pagewalk.)
When running a 32-bit PV guest on a 64-bit Xen, Xen must always OR
in the USER and RW bits for L3 updates for the guest to observe
architectural behaviour. This is unsafe in combination with
recursive pagetables.
As there is no way to construct an L3 recursive pagetable in native
32-bit PAE mode, disallow this option in 32-bit PV guests.
A malicious 32-bit PV guest administrator can escalate their
privilege to that of the host.
Discovery 2016-09-08 Entry 2016-12-04 xen-kernel
< 4.7.1
CVE-2016-7092
ports/214936
https://xenbits.xen.org/xsa/advisory-185.html
|
6aa2d135-b40e-11e5-9728-002590263bf5 | xen-kernel -- ioreq handling possibly susceptible to multiple read issue
The Xen Project reports:
Single memory accesses in source code can be translated to multiple
ones in machine code by the compiler, requiring special caution when
accessing shared memory. Such precaution was missing from the
hypervisor code inspecting the state of I/O requests sent to the
device model for assistance.
Due to the offending field being a bitfield, it is however believed
that there is no issue in practice, since compilers, at least when
optimizing (which is always the case for non-debug builds), should find
it more expensive to extract the bit field value twice than to keep the
calculated value in a register.
This vulnerability is exposed to malicious device models. In
conventional Xen systems this means the qemu which service an HVM
domain. On such systems this vulnerability can only be exploited if
the attacker has gained control of the device model qemu via another
vulnerability.
Privilege escalation, host crash (Denial of Service), and leaked
information all cannot be excluded.
Discovery 2015-12-17 Entry 2016-01-06 xen-kernel
< 4.5.2_1
ports/205841
http://xenbits.xen.org/xsa/advisory-166.html
|
523bb0b7-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- x86 task switch to VM86 mode mis-handled
The Xen Project reports:
LDTR, just like TR, is purely a protected mode facility. Hence even
when switching to a VM86 mode task, LDTR loading needs to follow
protected mode semantics. This was violated by the code.
On SVM (AMD hardware): a malicious unprivileged guest process can
escalate its privilege to that of the guest operating system.
On both SVM and VMX (Intel hardware): a malicious unprivileged
guest process can crash the guest.
Discovery 2016-11-22 Entry 2016-12-04 xen-kernel
< 4.7.1
CVE-2016-9382
ports/214936
https://xenbits.xen.org/xsa/advisory-192.html
|
bcad3faa-b40c-11e5-9728-002590263bf5 | xen-kernel -- XENMEM_exchange error handling issues
The Xen Project reports:
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.
A malicious guest administrator may be able to deny service by
crashing the host or causing a deadlock.
Discovery 2015-12-08 Entry 2016-01-06 xen-kernel
< 4.5.2_1
CVE-2015-8339
CVE-2015-8340
ports/205841
http://xenbits.xen.org/xsa/advisory-159.html
|
53dbd096-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- x86 segment base write emulation lacking canonical address checks
The Xen Project reports:
Both writes to the FS and GS register base MSRs as well as the
WRFSBASE and WRGSBASE instructions require their input values to be
canonical, or a #GP fault will be raised. When the use of those
instructions by the hypervisor was enabled, the previous guard
against #GP faults (having recovery code attached) was accidentally
removed.
A malicious guest administrator can crash the host, leading to a
DoS.
Discovery 2016-11-22 Entry 2016-12-04 xen-kernel
ge 4.4 lt 4.7.1
CVE-2016-9385
ports/214936
https://xenbits.xen.org/xsa/advisory-193.html
|