OVMSA-2016-0089 - xen security update
| Type: | SECURITY |
| Severity: | IMPORTANT |
| Release Date: | 2016-07-27 |
Description
[4.3.0-55.el6.119.49]
- x86/HVM: correct CPUID leaf 80000008 handling - 6c733e54
xsa173_01_0001-x86-HVM-correct-CPUID-leaf-80000008-handling.patch was based
on upstream commit:
ef437690af8b75e6758dce77af75a22b63982883
x86/HVM: correct CPUID leaf 80000008 handling
It should have been based on upstream commit:
6c733e549889a9b8c4e03140348b8e00241d4ce9
x86/HVM: correct CPUID leaf 80000008 handling
The changes in this patch are the differences between those two patches.
Signed-off-by: Chuck Anderson
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Boris Ostrovsky [bug 24351970]
[4.3.0-55.el6.119.48]
- x86: fix unintended fallthrough case from XSA-154
... and annotate the other deliberate one: Coverity objects otherwise.
Signed-off-by: Andrew Cooper
One of the two instances was actually a bug.
Signed-off-by: Jan Beulich
master commit: 8dd6d1c099865ee5f5916616a0ca79cd943c46f9
master date: 2016-02-18 15:10:07 +0100
Upstream commit ccc7adf9cff5d5f93720afcc1d0f7227d50feab2
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Reviewed-by: Chuck Anderson [bug 22752939] {CVE-2016-2270}
[4.3.0-55.el6.119.47]
- x86/pv: Remove unsafe bits from the mod_l?_entry() fastpath
All changes in writeability and cacheability must go through full
re-validation.
Rework the logic as a whitelist, to make it clearer to follow.
This is XSA-182
Signed-off-by: Andrew Cooper
Reviewed-by: Tim Deegan
Upstream commit 798c1498f764bfaa7b0b955bab40b01b0610d372
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 24307891]
[4.3.0-55.el6.119.46]
- libxl: Do not trust frontend for nic in getinfo
libxl_device_nic_getinfo needs to examine devices without trusting
frontend-controlled data. So:
* Use /libxl to find the backend path.
* Parse the backend path to find the backend domid, rather than
reading it from the frontend.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 5811d6bdf5bb6e80db7acaf8bab196f9476f5164
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.45]
- -bxl: Do not trust frontend for nic in libxl_devid_to_device_nic
Find the backend by reading the pointer in /libxl rather than in the
guests frontend area.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 2c74b8dd4c5d6982eee1fd852f9aa10ec1b24545
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
-This line, and those below, will be ignored--
? 0003-libxl-Do-not-trust-frontend-in-libxl__devices_destro.patch
? .0009-libxl-Do-not-trust-frontend-for-nic-in-libxl_devid_t.patch.swp
? 0001-libxl-Record-backend-frontend-paths-in-libxl-DOMID.patch
? 0004-libxl-Do-not-trust-frontend-in-libxl__device_nextid.patch
? 0007-libxl-Do-not-trust-frontend-for-vtpm-list.patch
? 0005-libxl-Do-not-trust-frontend-for-disk-eject-event.patch
? xsa176.patch
? 0008-libxl-Do-not-trust-frontend-for-vtpm-in-getinfo.patch
? 0009-libxl-Do-not-trust-frontend-for-nic-in-libxl_devid_t.patch
? 0002-libxl-Provide-libxl__backendpath_parse_domid.patch
? 0006-libxl-Do-not-trust-frontend-for-disk-in-getinfo.patch
? 0001-x86-mm-Handle-1GiB-superpages-in-the-pagetable-walke.patch
? 0007-libxl-Do-not-trust-frontend-for-vtpm-list.patch.1
? 0010-libxl-Do-not-trust-frontend-for-nic-in-getinfo.patch
? xsa180-qemut.patch
? xsa180-qemuu.patch
? tools/qemu-xen-traditional-dir/hw/xenfb.c.orig
? tools/qemu-xen-dir/hw/qxl.c.orig
? tools/qemu-xen-dir/hw/vga.c.orig
? tools/qemu-xen-dir/hw/vga_int.h.orig
? tools/blktap2/drivers/block-log.c.orig
? tools/libxl/libxl.c.orig
? tools/libxl/libxl_internal.h.orig
M tools/libxl/libxl.c
? xen/include/public/io/ring.h.orig
? xen/arch/x86/cpu/common.c.orig
? xen/arch/x86/hvm/mtrr.c.orig
? xen/arch/x86/hvm/hvm.c.orig
? xen/arch/x86/mm/hap/hap.c.orig [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.44]
- libxl: Do not trust frontend for vtpm in getinfo
libxl_device_vtpm_getinfo needs to examine devices without trusting
frontend-controlled data. So:
* Use /libxl to find the backend path.
* Parse the backend path to find the backend domid, rather than
reading it from the frontend.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 3544831133b19787fc3d9a27711ff9f647d0ddb8
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.43]
- libxl: Do not trust frontend for vtpm list
libxl_device_vtpm_list needs to enumerate and identify devices without
trusting frontend-controlled data. So
* Use the /libxl path to enumerate vtpms.
* Use the /libxl path to find the corresponding backends.
* Parse the backend path to find the backend domid.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 7bde3f4c5d36c8e7760f74aad52546162a62c2b4
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.42]
- libxl: Do not trust frontend for disk in getinfo
* Rename the frontend variable to fe_path to check we caught them all
* Read the backend path from /libxl, rather than from the frontend
* Parse the backend domid from the backend path, rather than reading it
from the frontend (and add the appropriate error path and initialisation)
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 38ef6689b7cf3904355f95a0c12d0b92e5ad2137
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.41]
- libxl: Do not trust frontend for disk eject event
Use the /libxl path for interpreting disk eject watch events: do not
read the backend path out of the frontend. Instead, use the version
in /libxl. That avoids us relying on the guest-modifiable
/backend pointer.
To implement this we store the path
/libxl//device/vbd//backend
in the evgen structure.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit babf4f45a52af68e58316c4456dffc97e0a1df79
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.40]
- libxl: Do not trust frontend in libxl__device_nextid
When selecting the devid for a new device, we should look in
/libxl/device for existing devices, not in the frontend area.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 13de0ee03135a08c4e8cefa1981d638bb4d5a561
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.39]
- libxl: Do not trust frontend in libxl__devices_destroy
We need to enumerate the devices we have provided to a domain, without
trusting the guest-writeable (or, at least, guest-deletable) frontend
paths.
Instead, enumerate via, and read the backend path from, /libxl.
The console /libxl path is regular, so the special case for console 0
is not relevant any more: /libxl/GUEST/device/console/0 will be found,
and then libxl__device_destroy will DTRT to the right frontend path.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 4a78d360241a4b97a22d83e6283e122a45ef96e3
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.38]
- libxl: Provide libxl__backendpath_parse_domid
Multiple places in libxl need to figure out the backend domid of a
device. This can be discovered easily by looking at the backend path,
which always starts /local/domain//.
There are no call sites yet.
This is part of XSA-175.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 89c6672d012890894105d7f832ddf4cbf8d56a15
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.37]
- libxl: Record backend/frontend paths in /libxl/
This gives us a record of all the backends we have set up for a
domain, which is separate from the frontends in
/local/domain//device.
In particular:
1. A guest has write permission for the frontend path:
/local/domain//device//
which means that the guest can completely delete the frontend.
(They cant recreate it because they dont have write permission
on the containing directory.)
2. A guest has write permission for the backend path recorded in the
frontend, ie, it can write to
/local/domain//device///backend
which means that the guest can break the association between
frontend and backend.
So we cant rely on iterating over the frontends to find all the
backends, or examining a frontend to discover how a device is
configured.
So, have libxl__device_generic_add record the frontend and backend
paths in /libxl//device, and have libxl__device_destroy remove
them again.
Create the containing directory /libxl/GUEST/device in
libxl__domain_make. The already existing xs_rm in devices_destroy_cb
will take care of removing it.
This is part of XSA-175.
Backport note: Backported over 7472ced, which fixes a bug in driver
domain teardown.
Signed-off-by: Ian Jackson
Reviewed-by: Wei Liu
Upstream commit 44ea68c6e6819ee535c4dd3d18a8691ff722d961
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530771] {CVE-2016-4962}
[4.3.0-55.el6.119.36]
- main loop: Big hammer to fix logfile disk DoS in Xen setups
Each time round the main loop, we now fstat stderr. If it is too big,
we dup2 /dev/null onto it. This is not a very pretty patch but it is
very simple, easy to see that its correct, and has a low risk of
collateral damage.
The limit is 1Mby by default but can be adjusted by setting a new
environment variable.
This fixes CVE-2014-3672.
Signed-off-by: Ian Jackson
Tested-by: Ian Jackson
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23531459] {CVE-2014-3672}
[4.3.0-55.el6.119.35]
- main loop: Big hammer to fix logfile disk DoS in Xen setups
Each time round the main loop, we now fstat stderr. If it is too big,
we dup2 /dev/null onto it. This is not a very pretty patch but it is
very simple, easy to see that its correct, and has a low risk of
collateral damage.
The limit is 1Mby by default but can be adjusted by setting a new
environment variable.
This fixes CVE-2014-3672.
Signed-off-by: Ian Jackson
Tested-by: Ian Jackson
---
v2: Make it actually compile. Fix a typo in the message.
Move the check_cve_2014_3672_xen up in the file, so that we can:
Call check_cve_2014_3672_xen in the other copy of the main loop (!)
Conflicts:
tools/qemu-xen-dir/main-loop.c
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23531459] {CVE-2014-3672}
[4.3.0-55.el6.119.34]
- x86/mm: fully honor PS bits in guest page table walks
In L4 entries it is currently unconditionally reserved (and hence
should, when set, always result in a reserved bit page fault), and is
reserved on hardware not supporting 1Gb pages (and hence should, when
set, similarly cause a reserved bit page fault on such hardware).
This is CVE-2016-4480 / XSA-176.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Tested-by: Andrew Cooper
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23531401] {CVE-2016-4480}
[4.3.0-55.el6.119.33]
- x86: limit GFNs to 32 bits for shadowed superpages.
Superpage shadows store the shadowed GFN in the backpointer field,
which for non-BIGMEM builds is 32 bits wide. Shadowing a superpage
mapping of a guest-physical address above 2^44 would lead to the GFN
being truncated there, and a crash when we come to remove the shadow
from the hash table.
Track the valid width of a GFN for each guest, including reporting it
through CPUID, and enforce it in the shadow pagetables. Set the
maximum witth to 32 for guests where this truncation could occur.
This is XSA-173.
Signed-off-by: Tim Deegan
Signed-off-by: Jan Beulich
Reported-by: Ling Liu
Upstream commit 95dd1b6e87b61222fc856724a5d828c9bdc30c80
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530694] {CVE-2016-3960}
[4.3.0-55.el6.119.32]
- x86/HVM: correct CPUID leaf 80000008 handling
CPUID[80000008].EAX[23:16] have been given the meaning of the guest
physical address restriction (in case it needs to be smaller than the
hosts), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
Enforce a lower limit at the same time, as well as a fixed value for
the virtual address bits, and zero for the guest physical address ones.
In order for the vMTRR code to see these overrides we need to make it
call hvm_cpuid() instead of domain_cpuid(), which in turn requires
special casing (and relaxing) the controlling domain.
This additionally should hide an ordering problem in the tools: Both
xend and xl appear to be restoring a guest from its image before
setting up the CPUID policy in the hypervisor, resulting in
domain_cpuid() returning all zeros and hence the check in
mtrr_var_range_msr_set() failing if the guest previously had more than
the minimum 36 physical address bits.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
Conflicts:
xen/arch/x86/hvm/mtrr.c
Upstream commit ef437690af8b75e6758dce77af75a22b63982883
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23530694] {CVE-2016-3960}
[4.3.0-55.el6.119.31]
- xenfb: avoid reading twice the same fields from the shared page
Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.
This is part of XSA-155.
Signed-off-by: Stefano Stabellini
Backported-by: Zhenzhong Duan [bug 23530451] {CVE-2015-8550}
[4.3.0-55.el6.119.30]
- xen/blkif: Avoid double access to src->nr_segments
src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function. If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.
Fix it by removing the double access to src->nr_segments.
This is part of XSA-155.
Signed-off-by: Stefano Stabellini
Backported-by: Zhenzhong Duan [bug 23530451] {CVE-2015-8550}
[4.3.0-55.el6.119.29]
- xenfb: avoid reading twice the same fields from the shared page
Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.
This is part of XSA-155.
Signed-off-by: Stefano Stabellini
Upsteam commit 0ffd4547665d2fec648ab2c9ff856c5d9db9b07c
Backported-by: Zhenzhong Duan
Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550}
[4.3.0-55.el6.119.28]
- blkif: Avoid double access to src->nr_segments
src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function. If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.
Fix it by removing the double access to src->nr_segments.
This is part of XSA-155.
Signed-off-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
Upsteam commit 27942b0cb2327e93deb12326bbe7b36c81f9fa7b
Backported-by: Zhenzhong Duan [bug 23530451] {CVE-2015-8550}
[4.3.0-55.el6.119.27]
- libvchan: Read prod/cons only once.
We must ensure that the prod/cons are only read once and that
the compiler wont try to optimize the reads. That is split
the read of these in multiple instructions influencing later
branch code. As such insert barriers when fetching the cons
and prod index.
This is part of XSA155.
Signed-off-by: Konrad Rzeszutek Wilk
Backported-by: Zhenzhong Duan
Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550}
[4.3.0-55.el6.119.26]
- blktap2: Use RING_COPY_REQUEST
Instead of RING_GET_REQUEST. Using a local copy of the
ring (and also with proper memory barriers) will mean
we can do not have to worry about the compiler optimizing
the code and doing a double-fetch in the shared memory space.
This is part of XSA155.
Signed-off-by: Konrad Rzeszutek Wilk
---
v2: Fix compile issues with tapdisk-vbd
Upsteam commit 851ffb4eea917e2708c912291dea4d133026c0ac
Backported-by: Zhenzhong Duan
Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550}
[4.3.0-55.el6.119.25]
- xen: Add RING_COPY_REQUEST()
Using RING_GET_REQUEST() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected). Safe usage of a request
generally requires taking a local copy.
Provide a RING_COPY_REQUEST() macro to use instead of
RING_GET_REQUEST() and an open-coded memcpy(). This takes care of
ensuring that the copy is done correctly regardless of any possible
compiler optimizations.
Use a volatile source to prevent the compiler from reordering or
omitting the copy.
This is part of XSA155.
Signed-off-by: David Vrabel
Signed-off-by: Konrad Rzeszutek Wilk
---
v2: Add comment about GCC bug.
Upsteam commit 12b11658a9d6a654a1e7acbf2f2d56ce9a396c86
Backported-by: Zhenzhong Duan
Acked-by: Chuck Anderson [bug 23530451] {CVE-2015-8550}
[4.3.0-55.el6.119.24]
- vga: make sure vga register setup for vbe stays intact
(CVE-2016-3712).
Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT
registers, to make sure the vga registers will always have the
values needed by vbe mode. This makes sure the sanity checks
applied by vbe_fixup_regs() are effective.
Without this guests can muck with shift_control, can turn on planar
vga modes or text mode emulation while VBE is active, making qemu
take code paths meant for CGA compatibility, but with the very
large display widths and heigts settable using VBE registers.
Which is good for one or another buffer overflow. Not that
critical as they typically read overflows happening somewhere
in the display code. So guests can DoS by crashing qemu with a
segfault, but it is probably not possible to break out of the VM.
Fixes: CVE-2016-3712
Reported-by: Zuozhi Fzz
Reported-by: P J P
Signed-off-by: Gerd Hoffmann
Signed-off-by: Stefano Stabellini
Upstream commit 0f2e9e6b3c75a87e9ec9a80d7bc914810e3f3da2
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.23]
- vga: update vga register setup on vbe changes
Call the new vbe_update_vgaregs() function on vbe configuration
changes, to make sure vga registers are up-to-date.
Signed-off-by: Gerd Hoffmann
Signed-off-by: Stefano Stabellini
Upstream commit 98be1fb6ea31c130264025de8ec87ad2c7532f21
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.22]
- vga: factor out vga register setup
When enabling vbe mode qemu will setup a bunch of vga registers to make
sure the vga emulation operates in correct mode for a linear
framebuffer. Move that code to a separate function so we can call it
from other places too.
Signed-off-by: Gerd Hoffmann
Signed-off-by: Stefano Stabellini
Upstream commit 2700250c6b28248b70b15fd6e0b4c9db8b2ddfb7
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.21]
- vga: add vbe_enabled() helper
Makes code a bit easier to read.
Signed-off-by: Gerd Hoffmann
Signed-off-by: Stefano Stabellini
Upstream commit e7d7c09689c725be4f0b489b4ba3b741c5d9ab31
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.20]
- vbe: rework sanity checks
Plug a bunch of holes in the bochs dispi interface parameter checking.
Add a function doing verification on all registers. Call that
unconditionally on every register write. That way we should catch
everything, even changing one register affecting the valid range of
another register.
Some of the holes have been added by commit
e9c6149f6ae6873f14a12eea554925b6aa4c4dec. Before that commit the
maximum possible framebuffer (VBE_DISPI_MAX_XRES * VBE_DISPI_MAX_YRES *
32 bpp) has been smaller than the qemu vga memory (8MB) and the checking
for VBE_DISPI_MAX_XRES + VBE_DISPI_MAX_YRES + VBE_DISPI_MAX_BPP was ok.
Some of the holes have been there forever, such as
VBE_DISPI_INDEX_X_OFFSET and VBE_DISPI_INDEX_Y_OFFSET register writes
lacking any verification.
Security impact:
(1) Guest can make the ui (gtk/vnc/...) use memory rages outside the vga
frame buffer as source -> host memory leak. Memory isnt leaked to
the guest but to the vnc client though.
(2) Qemu will segfault in case the memory range happens to include
unmapped areas -> Guest can DoS itself.
The guest can not modify host memory, so I dont think this can be used
by the guest to escape.
CVE-2014-3615
Cc: qemu-stable@nongnu.org
Cc: secalert@redhat.com
Signed-off-by: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
Conflicts:
hw/vga.c
Upstream commit c1b886c45dc70f247300f549dce9833f3fa2def5
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.19]
- vbe: make bochs dispi interface return the correct memory size with qxl
VgaState->vram_size is the size of the pci bar. In case of qxl not the
whole pci bar can be used as vga framebuffer. Add a new variable
vbe_size to handle that case. By default (if unset) it equals
vram_size, but qxl can set vbe_size to something else.
This makes sure VBE_DISPI_INDEX_VIDEO_MEMORY_64K returns correct results
and sanity checks are done with the correct size too.
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
Conflicts:
hw/qxl.c
hw/vga.c
hw/vga_init.c
Upstream commit 54a85d462447c1cb8a1638578a7fd086350b4d2d
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.18]
- vga: fix banked access bounds checking (CVE-2016-3710)
vga allows banked access to video memory using the window at 0xa00000
and it supports a different access modes with different address
calculations.
The VBE bochs extentions support banked access too, using the
VBE_DISPI_INDEX_BANK register. The code tries to take the different
address calculations into account and applies different limits to
VBE_DISPI_INDEX_BANK depending on the current access mode.
Which is probably effective in stopping misprogramming by accident.
But from a security point of view completely useless as an attacker
can easily change access modes after setting the bank register.
Drop the bogus check, add range checks to vga_mem_{readb,writeb}
instead.
Fixes: CVE-2016-3710
Reported-by: Qinghao Tang
Signed-off-by: Gerd Hoffmann
Signed-off-by: Stefano Stabellini
Upstream commit 67305fcf4733fb4fb9eacc33436ec66a7c0352ef
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3710}
[4.3.0-55.el6.119.17]
- vga: make sure vga register setup for vbe stays intact
(CVE-2016-3712).
Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT
registers, to make sure the vga registers will always have the
values needed by vbe mode. This makes sure the sanity checks
applied by vbe_fixup_regs() are effective.
Without this guests can muck with shift_control, can turn on planar
vga modes or text mode emulation while VBE is active, making qemu
take code paths meant for CGA compatibility, but with the very
large display widths and heigts settable using VBE registers.
Which is good for one or another buffer overflow. Not that
critical as they typically read overflows happening somewhere
in the display code. So guests can DoS by crashing qemu with a
segfault, but it is probably not possible to break out of the VM.
Fixes: CVE-2016-3712
Reported-by: Zuozhi Fzz
Reported-by: P J P
Signed-off-by: Gerd Hoffmann
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper
Upstream commit 0b0cf8110e97b0cbd0da73d11163e26978822757
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.16]
- vga: update vga register setup on vbe changes
Call the new vbe_update_vgaregs() function on vbe configuration
changes, to make sure vga registers are up-to-date.
Signed-off-by: Gerd Hoffmann
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper
Upstream commit 5e840e6292825fcae90f6750a8f57bc989e28c5f
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.15]
- vga: factor out vga register setup
When enabling vbe mode qemu will setup a bunch of vga registers to make
sure the vga emulation operates in correct mode for a linear
framebuffer. Move that code to a separate function so we can call it
from other places too.
Signed-off-by: Gerd Hoffmann
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper
Upstream commit df228023ce39e8b72bd5a198b8703319b8b9ca23
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.14]
- vga: add vbe_enabled() helper
Makes code a bit easier to read.
Signed-off-by: Gerd Hoffmann
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper
Upstream commit 34db09fb9967441408a1ff0579d553222cf17441
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.13]
- CVE-2014-3615: vbe: rework sanity checks
Backport of qemu-upstream:
* c1b886c45dc70f247300f549dce9833f3fa2def5
Signed-off-by: Andrew Cooper
Upstream commit 8a1e383df25477e21b48c67c93c3a4dde19f9e4f
Prerequisite commit for CVE-2016-3712
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3712}
[4.3.0-55.el6.119.12]
- vga: fix banked access bounds checking (CVE-2016-3710)
vga allows banked access to video memory using the window at 0xa00000
and it supports a different access modes with different address
calculations.
The VBE bochs extentions support banked access too, using the
VBE_DISPI_INDEX_BANK register. The code tries to take the different
address calculations into account and applies different limits to
VBE_DISPI_INDEX_BANK depending on the current access mode.
Which is probably effective in stopping misprogramming by accident.
But from a security point of view completely useless as an attacker
can easily change access modes after setting the bank register.
Drop the bogus check, add range checks to vga_mem_{readb,writeb}
instead.
Fixes: CVE-2016-3710
Reported-by: Qinghao Tang
Signed-off-by: Gerd Hoffmann
[Backport to qemu-xen-tradition]
Signed-off-by: Andrew Cooper
Upstream commit bebb4f580901fb638016d9851a28dbb83d44b3a6
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky [bug 23263099] {CVE-2016-3710}
[4.3.0-55.el6.119.11]
- x86: fix information leak on AMD CPUs
The fix for XSA-52 was wrong, and so was the change synchronizing that
new behavior to the FXRSTOR logic: AMDs manuals explictly state that
writes to the ES bit are ignored, and it instead gets calculated from
the exception and mask bits (it gets set whenever there is an unmasked
exception, and cleared otherwise). Hence we need to follow that model
in our workaround.
This is XSA-172 / CVE-2016-3158.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Acked-by: Chuck Anderson
Reviewed-by: Boris Ostrovsky
Tested-by: Boris Ostrovsky [bug 23006897] {CVE-2016-3158,CVE-2016-3159}
Related CVEs
Updated Packages
| Release/Architecture | Filename | MD5sum | Superseded By Advisory |
|
| Oracle VM 3.3 (x86_64) | xen-4.3.0-55.el6.119.49.src.rpm | d686cd4cfa8afefa519e7172889e79e9 | OVMSA-2021-0014 |
| xen-4.3.0-55.el6.119.49.x86_64.rpm | ebc5cb458651e284263203a553f31e14 | OVMSA-2021-0014 |
| xen-tools-4.3.0-55.el6.119.49.x86_64.rpm | e776f37bc91c7d912cec106160a58a42 | OVMSA-2021-0014 |
This page is generated automatically and has not been checked for errors or omissions. For clarification
or corrections please contact the Oracle Linux ULN team
