|Public release ||2016-11-22 12:00|
|Updated ||2016-11-22 12:00|
|Title ||x86 64-bit bit test instruction emulation broken|
Filesadvisory-195.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2016-9383 / XSA-195
x86 64-bit bit test instruction emulation broken
UPDATES IN VERSION 3
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
When Xen needs to emulate such an instruction, to efficiently handle
the emulation, the memory address and register operand are
recalculated internally to Xen. In this process, the high bits of an
intermediate expression were discarded, leading to both the memory
location and the register operand being wrong.
The wrong memory location would have only a guest local effect (either
access to an unintended location, or a fault delivered to the guest),
whereas the wrong register value could lead to either a host crash or
an unintended host memory access.
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
All Xen versions are affected.
The vulnerability is only exposed to x86 guests running in 64-bit mode.
On Xen 4.6 and earlier the vulnerability is exposed to all guest user
processes, including unprivileged processes, in such guests.
On Xen 4.7 and later, the vulnerability is exposed only to guest user
processes granted a degree of privilege (such as direct hardware
access) by the guest administrator; or, to all user processes when the
when the VM has been explicitly configured with a non-default cpu
vendor string (in xm/xl, this would be done with a `cpuid=' domain
The vulnerability is not exposed to 32-bit PV guests.
ARM systems are not vulnerable.
There is no known mitigation.
This issue was discovered by George Dunlap of Citrix, using American
Fuzzy Lop v2.35b.
Applying the attached patch resolves this issue.
xsa195.patch xen-unstable, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x
$ sha256sum xsa195*
DEPLOYMENT DURING EMBARGO
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
Xenproject.org Security Team