Commit e466dbbf authored by Natanael Copa's avatar Natanael Copa

main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)

ref #2044
ref #2049
ref #2054
fixes #2046
fixes #2051
fixes #2056
(cherry picked from commit f6e99451)

Conflicts:
	main/xen/APKBUILD
parent f63fa9cc
......@@ -3,7 +3,7 @@
# Maintainer: William Pitcock <nenolod@dereferenced.org>
pkgname=xen
pkgver=4.2.1
pkgrel=11
pkgrel=12
pkgdesc="Xen hypervisor"
url="http://www.xen.org/"
arch="x86 x86_64"
......@@ -28,10 +28,13 @@ source="http://bits.xensource.com/oss-xen/release/$pkgver/$pkgname-$pkgver.tar.g
xsa35-4.2-with-xsa34.patch
xsa36-4.2.patch
xsa38.patch
xsa47-4.2-unstable.patch
xsa48-4.2.patch
xsa44-4.2.patch
xsa46-4.2.patch
xsa47-4.2-unstable.patch
xsa48-4.2.patch
xsa52-4.2-unstable.patch
xsa53-4.2.patch
xsa54.patch
xsa56.patch
xenstored.initd
......@@ -155,10 +158,13 @@ af10e1a3f757a184a1d79904a5ef8572 xsa34-4.2.patch
8270dbf929e26b5e95532d10a697e404 xsa35-4.2-with-xsa34.patch
87a54b2a1f1ea3d955017fe1fd8c0398 xsa36-4.2.patch
47589e06d077d71282ec1b87dd4d87a9 xsa38.patch
c05bb12fc5b6aa64cd23f2ad623c539a xsa47-4.2-unstable.patch
b3e3a57d189a4f86c9766eaf3b5207f4 xsa48-4.2.patch
85239ba26395b05502ceee5eec968ea7 xsa44-4.2.patch
b955534323681fa461f86c69e4acec75 xsa46-4.2.patch
c05bb12fc5b6aa64cd23f2ad623c539a xsa47-4.2-unstable.patch
b3e3a57d189a4f86c9766eaf3b5207f4 xsa48-4.2.patch
83a9cdd035bcd18bf035434a1ba08c38 xsa52-4.2-unstable.patch
03a1a4ebc470ee7e638e04db2701a4f7 xsa53-4.2.patch
a8393d1ec6b886ea72ffe624a04ee10a xsa54.patch
e70b9128ffc2175cea314a533a7d8457 xsa56.patch
95d8af17bf844d41a015ff32aae51ba1 xenstored.initd
b017ccdd5e1c27bbf1513e3569d4ff07 xenstored.confd
......@@ -171,61 +177,3 @@ fa8c72b42e0479d521a353386d8543ef xendomains.initd
9df68ac65dc3f372f5d61183abdc83ff xen-consoles.logrotate
6a2f777c16678d84039acf670d86fff6 xenqemu.confd
f9afbf39e2b5a7d9dde60ebbd249ea7d xenqemu.initd"
sha256sums="fb8df5827ce3e2d2d3b078d9e5afde502beb5e7ab9442e51a94087061bd450c6 xen-4.2.1.tar.gz
4fb92fa1ce67eb3f78a15c6c971415d4d53599904969596acc7a52edc83a5fee qemu_uclibc_configure.patch
12bf32f9937b09283f2df4955b50d6739768f66137a7d991f661f45cf77cb53b librt.patch
9440ca31a6911201f02694e93faafb5ca9b17de18b7f15b53ceac39a03411b4a qemu-xen_paths.patch
a0c225d716d343fe041b63e3940900c5b3573ed3bcfc5b7c2d52ea2861c3fc28 docs-Fix-generating-qemu-doc.html-with-texinfo-5.patch
ba05474b8e1232318ae010d63d24ff1b15ba4d83e28cdb69d6a76e8f9eb5292c xsa33-4.2-unstable.patch
93452beba88a8da8e89b8bfa743074a358ba1d9052151c608e21c4d62f8c4867 xsa41.patch
896a07f57310c9bea9bc2a305166cf796282c381cb7839be49105b1726a860b5 xsa41b.patch
683dd96a0a8899f794070c8c09643dfeeb39f92da531955cba961b45f6075914 xsa41c.patch
ef75cdcf934003aaced57698a2441c4ba058b968956925eec2d5a100a28db0ae xsa34-4.2.patch
4a103bf14dd060f702289db539a8c6c69496bdfd1de5d0c0468c3aab7b34f6a5 xsa35-4.2-with-xsa34.patch
6848712b560b522f7d3cede53e29e799624311e7dee6e450f0c02c165a590783 xsa36-4.2.patch
7d7a5746bc76da747bf61eb87b3303a8f3abb0d96561f35a706c671317ebe4eb xsa38.patch
c29b59492f9d7e3f74bfc41877a2c5cff70436d3738fd91066f396f969aab0a7 xsa47-4.2-unstable.patch
dc23077028584e71a08dd0dc9e81552c76744a5ce9d39df5958a95ae9cf3107b xsa48-4.2.patch
c6c3afa228426d78e0484b7ac34210f642f79add35c4a04ca5ff7db5f2539e49 xsa44-4.2.patch
822da2303f1fc69648d7a29eb72fdda8e64baab3edc0e1548456d31e66ed1d7c xsa46-4.2.patch
a691c5f5332a42c0d38ddb4dc037eb902f01ba31033b64c47d02909a8de0257d xsa56.patch
81d335946c81311c86e2f2112b773a568a5a530c0db9802b2fe559e71bb8b381 xenstored.initd
ea9171e71ab3d33061979bcf3bb737156192aa4b0be4d1234438ced75b6fdef3 xenstored.confd
93bea2eb90ea1b4628854c8141dd351bbd1fbc5959b12795447ea933ad025f01 xenconsoled.initd
2a74be03eb74f6013242a4a5d721df6cb9b959b43c405de1e32813f52d749060 xenconsoled.confd
a50a4485e84bcc098ad021556cd2aa7947c228f0a546ab942e880787ced57be3 xend.initd
7f7a96349084474b76af98426387fec12a0684f505d1691091ac3d2556bde2de xend.confd
794bed4882cdce8d9ac91d9afc0d5da0f0ac97f38d90c5e965363139a834602d xendomains.initd
2360b1fa1f102ac1b1a6cd0d161a94d13139dfc21d9a2227d35d557b4f04a63e xendomains.confd
0da87a4b9094f934e3de937e8ef8d3afc752e76793aa3d730182d0241e118b19 xen-consoles.logrotate
4cfcddcade5d055422ab4543e8caa6e5c5eee7625c41880a9000b7a87c7c424e xenqemu.confd
bf17808a79c57a9efc38b9f14cc87f556b2bb7ecfdec5763d9cf686255a47fce xenqemu.initd"
sha512sums="fe27a965e2b34035bd025482eda9fc4d4e82523c929323fd30813367d5ffbe2fa1ed3d7d4479f2632e8b5625972448b7bd6a7768e8dc1dcd1b6747d281cc1a9e xen-4.2.1.tar.gz
81a5555c123daad6a9a1835186a82d604e68d833efe3a6576a88717268e5335f809a6621846645c2e1eb1d33a51951a6306e4c393a76c677959149bc28a886be qemu_uclibc_configure.patch
74e3cfc51e367fc445cb3d8149f0c8830e94719a266daf04d2cd0889864591860c4c8842de2bc78070e4c5be7d14dfbb8b236c511d5faeddc2ad97177c1d3764 librt.patch
425149aea57a6deae9f488cea867f125983998dc6e8c63893fb3b9caf0ea34214251dd98ad74db823f5168631c44c49b988b6fe9c11b76bd493ddf51bc0baaa2 qemu-xen_paths.patch
477d3d08bd4fcdfbc54abea1a18acb6a41d298c366cd01c954f474515cb862d0dd59217c0dfca5460a725a8bc036de42132f522c3eefdffcc4fd511f016b783f docs-Fix-generating-qemu-doc.html-with-texinfo-5.patch
e29d80c58c84fad9d68cb9789c1fd9c1694f0b0c96b55c2172502d4b32db3af541c377d19cf1aa88eb1687ddf818870a8afa171a9ef17f317a51fba8991eedb4 xsa33-4.2-unstable.patch
94672a4d37db4e370370157cac9507ee1a75832f4be779fba148c1faa0b18f26ed57126eee6256ccd5d218463325a730266b53139554f4865adedb7659154c16 xsa41.patch
bda9105793f2327e1317991762120d0668af0e964076b18c9fdbfd509984b2e88d85df95702c46b2e00d5350e8113f6aa7b34b19064d19abbeb4d43f0c431d38 xsa41b.patch
36b60478660ff7748328f5ab9adff13286eee1a1bad06e42fdf7e6aafe105103988525725aacd660cf5b2a184a9e2d6b3818655203c1fa07e07dcebdf23f35d9 xsa41c.patch
0647841dd220bfe08e6382bb19ae6cb204887e4ef58ecc616bb2ee454e6b28abac225a68ba5f7736972da899284d718ec077bf3ac0045a0a370086c225314678 xsa34-4.2.patch
6ce446fd561d38873d27efe2a874a745381bca40a73bb2564dc0e3f4733c3382cd2cdda134d0419c53e2b97b751dd190ebeb3cf885f7ee9671f232c6a2432c27 xsa35-4.2-with-xsa34.patch
90f7b880cb05c0214af37feb6fb4ea7475d2fa7c653c80fbcaef09d8dcdc480732564203c18e3c828ade6f247850427f8d3d368cac640003e00af9863effdd19 xsa36-4.2.patch
2abe25c83a3ede047db380b0477ba1aaaf9d955e87244f8d2404699e011cac46ad5501a0f75b76b90b5dc276d19ae08600a2fe57a69681f97088b5d17d977066 xsa38.patch
aac646828703eb1f4cf9a94a29eec4901c7fcc37e86e06f60530bee40259bd789d1749d844b341aeda307bc5860f72375618cc169819fef5778679789703d7cb xsa47-4.2-unstable.patch
31dd8c62d41cc0a01a79d9b24a5b793f5e2058230808d9c5364c6ff3477ab02f3258f1bbd761d97dc1b97ee120b41524b999eaac77f33b606496fc324b5fa2e4 xsa48-4.2.patch
cfcf8d1af07032bfd3ff9c7a76a8f7d8c6f8b3b084712a494c3ca7624d9a03cbb7cad723b5a1dbc2a99e18a7046c221fae743c8dc42ba09b463f02fd069254d9 xsa44-4.2.patch
35ed4d580d219e977ee1085c223563f51ccd9ce3675df2660d10d99c366a2fe2446269c98ac9dbf57c37de83340f4b0868d0eb3c5d898be4c0fc80357f6ed780 xsa46-4.2.patch
26a1c2cc92ddd4c1ab6712b0e41a0135d0e76a7fe3a14b651fb0235e352e5a24077414371acccb93058b7ce4d882b667386811170ba74570c53165837bcd983d xsa56.patch
792b062e8a16a2efd3cb4662d379d1500527f2a7ca9228d7831c2bd34f3b9141df949153ea05463a7758c3e3dd9a4182492ad5505fa38e298ecf8c99db77b4ee xenstored.initd
100cf4112f401f45c1e4e885a5074698c484b40521262f6268fad286498e95f4c51e746f0e94eb43a590bb8e813a397bb53801ccacebec9541020799d8d70514 xenstored.confd
12f981b2459c65d66e67ec0b32d0d19b95a029bc54c2a79138cfe488d3524a22e51860f755abfe25ddcdaf1b27f2ded59b6e350b9d5f8791193d00e2d3673137 xenconsoled.initd
30df69cc38d0bed26bc4d6e08a2b62cbdc654d5f663009a05cb3b83b3e3dc5e206362d3fd59abbb753ceb8d6d79eaa6e15d079bb8f4f35dc74667103faf4e85d xenconsoled.confd
55766e22d9374b404b96fba9d30aee49bee6c95fabce9c3d2aed1faba04c1573ecd75fe49e27ce1527ecf9064f53ccc15e4c69a1aa4ea3daa44828f38d687d85 xend.initd
39b38156f0a8498dbbe9aa58d320b85473d0999d62d2e33bb6bf53627fc41f2c67ec318dfab70d2063799f4cd9eeadc015b66fbb211ee3ef765492421a718608 xend.confd
1bef9f2905a4e62f4f2d22c0b8ae9779d9b9ab7a7dbd37a13afa6f21102c7b38cae0b2b11ab5637faad20b026e6a69416fd5e9a39f82da6c4c117784f8acbb53 xendomains.initd
7c1e32d07aefbde1904ca2d98f9a415543cea7ab8e039b05e0b111e37e78c07c40b540e439b3656d5840dfd76e35e07cf1d6ddea431163d975b1ddf5ddac50d3 xendomains.confd
ab2105c75cfe01768aecd5bcbb56269d63666e8a44e42b6a83aee87df6c84ee2f9ab249171c21b2e09f8fec2cae8318f6e87d160989398a3e7dd68db8d52c426 xen-consoles.logrotate
bdbe15c924071cdc2d0f23e53ba8e3f837d4b5369bfb218abd3405f9bef25d105269aaf0784baeb69c073a5786b8c82ffdfd414e86874da34293cfdc2c497928 xenqemu.confd
2341a01a000e4badd9dbfd122e7eb3e594982921a80186c0e4174744daf31114c384b42458864d9904ed1b463746efb774efa707ad48280a25ce897ef5ac9e83 xenqemu.initd"
x86/xsave: fix information leak on AMD CPUs
Just like for FXSAVE/FXRSTOR, XSAVE/XRSTOR also don't save/restore the
last instruction and operand pointers as well as the last opcode if
there's no pending unmasked exception (see CVE-2006-1056 and commit
9747:4d667a139318).
While the FXSR solution sits in the save path, I prefer to have this in
the restore path because there the handling is simpler (namely in the
context of the pending changes to properly save the selector values for
32-bit guest code).
Also this is using FFREE instead of EMMS, as it doesn't seem unlikely
that in the future we may see CPUs with x87 and SSE/AVX but no MMX
support. The goal here anyway is just to avoid an FPU stack overflow.
I would have preferred to use FFREEP instead of FFREE (freeing two
stack slots at once), but AMD doesn't document that instruction.
This is CVE-2013-2076 / XSA-52.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -78,6 +78,21 @@ void xrstor(struct vcpu *v, uint64_t mas
struct xsave_struct *ptr = v->arch.xsave_area;
+ /*
+ * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
+ * is pending. Clear the x87 state here by setting it to fixed
+ * values. The hypervisor data segment can be sometimes 0 and
+ * sometimes new user value. Both should be ok. Use the FPU saved
+ * data block as a safe address because it should be in L1.
+ */
+ if ( (mask & ptr->xsave_hdr.xstate_bv & XSTATE_FP) &&
+ !(ptr->fpu_sse.fsw & 0x0080) &&
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ asm volatile ( "fnclex\n\t" /* clear exceptions */
+ "ffree %%st(7)\n\t" /* clear stack tag */
+ "fildl %0" /* load to clear state */
+ : : "m" (ptr->fpu_sse) );
+
asm volatile (
".byte " REX_PREFIX "0x0f,0xae,0x2f"
:
x86/xsave: recover from faults on XRSTOR
Just like FXRSTOR, XRSTOR can raise #GP if bad content is being passed
to it in the memory block (i.e. aspects not under the control of the
hypervisor, other than e.g. proper alignment of the block).
Also correct the comment explaining why FXRSTOR needs exception
recovery code to not wrongly state that this can only be a result of
the control tools passing a bad image.
This is CVE-2013-2077 / XSA-53.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -53,7 +53,7 @@ static inline void fpu_fxrstor(struct vc
/*
* FXRSTOR can fault if passed a corrupted data block. We handle this
* possibility, which may occur if the block was passed to us by control
- * tools, by silently clearing the block.
+ * tools or through VCPUOP_initialise, by silently clearing the block.
*/
asm volatile (
#ifdef __i386__
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -93,10 +93,25 @@ void xrstor(struct vcpu *v, uint64_t mas
"fildl %0" /* load to clear state */
: : "m" (ptr->fpu_sse) );
- asm volatile (
- ".byte " REX_PREFIX "0x0f,0xae,0x2f"
- :
- : "m" (*ptr), "a" (lmask), "d" (hmask), "D"(ptr) );
+ /*
+ * XRSTOR can fault if passed a corrupted data block. We handle this
+ * possibility, which may occur if the block was passed to us by control
+ * tools or through VCPUOP_initialise, by silently clearing the block.
+ */
+ asm volatile ( "1: .byte " REX_PREFIX "0x0f,0xae,0x2f\n"
+ ".section .fixup,\"ax\"\n"
+ "2: mov %5,%%ecx \n"
+ " xor %1,%1 \n"
+ " rep stosb \n"
+ " lea %2,%0 \n"
+ " mov %3,%1 \n"
+ " jmp 1b \n"
+ ".previous \n"
+ _ASM_EXTABLE(1b, 2b)
+ : "+&D" (ptr), "+&a" (lmask)
+ : "m" (*ptr), "g" (lmask), "d" (hmask),
+ "m" (xsave_cntxt_size)
+ : "ecx" );
}
bool_t xsave_enabled(const struct vcpu *v)
x86/xsave: properly check guest input to XSETBV
Other than the HVM emulation path, the PV case so far failed to check
that YMM state requires SSE state to be enabled, allowing for a #GP to
occur upon passing the inputs to XSETBV inside the hypervisor.
This is CVE-2013-2078 / XSA-54.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2205,6 +2205,11 @@ static int emulate_privileged_op(struct
if ( !(new_xfeature & XSTATE_FP) || (new_xfeature & ~xfeature_mask) )
goto fail;
+ /* YMM state takes SSE state as prerequisite. */
+ if ( (xfeature_mask & new_xfeature & XSTATE_YMM) &&
+ !(new_xfeature & XSTATE_SSE) )
+ goto fail;
+
v->arch.xcr0 = new_xfeature;
v->arch.xcr0_accum |= new_xfeature;
set_xcr0(new_xfeature);
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment