VuXML ID | Description |
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
|
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
|
5555120d-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- guest 32-bit ELF symbol table load leaking host data
The Xen Project reports:
Along with their main kernel binary, unprivileged guests may
arrange to have their Xen environment load (kernel) symbol tables
for their use. The ELF image metadata created for this purpose has a
few unused bytes when the symbol table binary is in 32-bit ELF
format. These unused bytes were not properly cleared during symbol
table loading.
A malicious unprivileged guest may be able to obtain sensitive
information from the host.
The information leak is small and not under the control of the
guest, so effectively exploiting this vulnerability is probably
difficult.
Discovery 2016-11-22 Entry 2016-12-04 xen-kernel
ge 4.7 lt 4.7.1
CVE-2016-9384
ports/214936
https://xenbits.xen.org/xsa/advisory-194.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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
49211361-ba4d-11e6-ae1b-002590263bf5 | xen-kernel -- x86: Mishandling of instruction pointer truncation during emulation
The Xen Project reports:
When emulating HVM instructions, Xen uses a small i-cache for
fetches from guest memory. The code that handles cache misses does
not check if the address from which it fetched lies within the cache
before blindly writing to it. As such it is possible for the guest
to overwrite hypervisor memory.
It is currently believed that the only way to trigger this bug is
to use the way that Xen currently incorrectly wraps CS:IP in 16 bit
modes. The included patch prevents such wrapping.
A malicious HVM guest administrator can escalate their privilege to
that of the host.
Discovery 2016-09-08 Entry 2016-12-04 xen-kernel
eq 4.5.3
eq 4.6.3
ge 4.7.0 lt 4.7.1
CVE-2016-7093
ports/214936
https://xenbits.xen.org/xsa/advisory-186.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
|
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
|