X-Original-To: alpine-aports@lists.alpinelinux.org Received: from mx2.cde.us.jw.org (unknown [50.56.176.215]) by lists.alpinelinux.org (Postfix) with ESMTP id 82DA65C44C1 for ; Thu, 1 Dec 2016 07:55:07 +0000 (GMT) Received: from mx2.cde.us.jw.org (localhost [127.0.0.1]) by mx2.cde.us.jw.org (Postfix) with ESMTP id 04A1ADFB1E for ; Thu, 1 Dec 2016 07:55:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cde.us.jw.org; h=to:from :subject:message-id:date:mime-version:content-type; s=selector1; bh=7wL3Hh8PNsbSBAP/mW9QdDo/WII=; b=l/IJPj1BgrWAm+FwZknHAcU0jP+N 8tnOjTK9f7R1ua8UWUxE8gJ+DM9W89cB+uGIRpTxOvISlbvzNAsPPR/2Gqcz5YIe mx/r9BYgCSlikdPB/F2zbrXAFuZiVaHM7whuIZWgqDgRvUJfkSPOht4QBj/cjzzd 5dfsspiRCLd0SS0= Received: from [10.252.5.142] (unknown [83.145.235.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slukins) by mx2.cde.us.jw.org (Postfix) with ESMTPSA id 7B7A9DFB1C for ; Thu, 1 Dec 2016 07:55:06 +0000 (GMT) To: alpine-aports@lists.alpinelinux.org From: Sergey Lukin Subject: [alpine-aports] v3.4 main/xen: security upgrade - fixes #6496 (CVE-2016-9386, CVE-2016-9382, CVE-2016-9385, CVE-2016-9383, CVE-2016-9377, CVE-2016-9378, CVE-2016-9381, CVE-2016-9379, CVE-2016-9380) Message-ID: <469052d9-fffc-bb92-f8a2-c374728eb49c@cde.us.jw.org> Date: Thu, 1 Dec 2016 09:55:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 X-Mailinglist: alpine-aports Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------8602A576E307371162FD1B81" This is a multi-part message in MIME format. --------------8602A576E307371162FD1B81 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit --------------8602A576E307371162FD1B81 Content-Type: text/x-patch; name="AL_v3.4-xen-security-upgr-fix-6496.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="AL_v3.4-xen-security-upgr-fix-6496.patch" >From 78b121b37bec4f6599b239f61893aa5786246903 Mon Sep 17 00:00:00 2001 From: Sergey Lukin Date: Thu, 1 Dec 2016 07:38:29 +0000 Subject: [PATCH] v3.4 main/xen: security upgrade - fixes: #6496 (CVE-2016-9386, CVE-2016-9382, CVE-2016-9385, CVE-2016-9383, CVE-2016-9377, CVE-2016-9378, CVE-2016-9381, CVE-2016-9379, CVE-2016-9380) --- main/xen/APKBUILD | 38 +++++- main/xen/xsa191-4.6-CVE-2016-9386.patch | 138 +++++++++++++++++++++ main/xen/xsa192-CVE-2016-9382.patch | 64 ++++++++++ main/xen/xsa193-4.7-CVE-2016-9385.patch | 68 ++++++++++ main/xen/xsa195-CVE-2016-9383.patch | 45 +++++++ ...entry-calculation-in-inject-CVE-2016-9377.patch | 61 +++++++++ ...tion-of-software-interrupts-CVE-2016-9378.patch | 76 ++++++++++++ main/xen/xsa197-4.6-qemuu-CVE-2016-9381.patch | 63 ++++++++++ main/xen/xsa197-qemut-CVE-2016-9381.patch | 65 ++++++++++ main/xen/xsa198-CVE-2016-9379-CVE-2016-9380.patch | 62 +++++++++ 10 files changed, 679 insertions(+), 1 deletion(-) create mode 100644 main/xen/xsa191-4.6-CVE-2016-9386.patch create mode 100644 main/xen/xsa192-CVE-2016-9382.patch create mode 100644 main/xen/xsa193-4.7-CVE-2016-9385.patch create mode 100644 main/xen/xsa195-CVE-2016-9383.patch create mode 100644 main/xen/xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch create mode 100644 main/xen/xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch create mode 100644 main/xen/xsa197-4.6-qemuu-CVE-2016-9381.patch create mode 100644 main/xen/xsa197-qemut-CVE-2016-9381.patch create mode 100644 main/xen/xsa198-CVE-2016-9379-CVE-2016-9380.patch diff --git a/main/xen/APKBUILD b/main/xen/APKBUILD index 2131d1d..5558996 100644 --- a/main/xen/APKBUILD +++ b/main/xen/APKBUILD @@ -3,7 +3,7 @@ # Maintainer: William Pitcock pkgname=xen pkgver=4.6.3 -pkgrel=4 +pkgrel=5 pkgdesc="Xen hypervisor" url="http://www.xen.org/" arch="x86_64" @@ -64,6 +64,15 @@ source="http://bits.xensource.com/oss-xen/release/$pkgver/$pkgname-$pkgver.tar.g xsa187-4.7-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg.patch xsa187-4.6-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch xsa190-4.6.patch + xsa191-4.6-CVE-2016-9386.patch + xsa192-CVE-2016-9382.patch + xsa193-4.7-CVE-2016-9385.patch + xsa195-CVE-2016-9383.patch + xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch + xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch + xsa197-4.6-qemuu-CVE-2016-9381.patch + xsa197-qemut-CVE-2016-9381.patch + xsa198-CVE-2016-9379-CVE-2016-9380.patch xenstore_client_transaction_fix.patch qemu-coroutine-gthread.patch @@ -270,6 +279,15 @@ cc0904605d03a9e4f6f21d16824e41c9 xsa184-qemuu-master.patch c426383254acdcbb9466bbec2d6f8d9b xsa187-4.7-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg.patch a98c0fa2579965d72272f381f193195d xsa187-4.6-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch 2c6f0d0ec618a832cc4f5316624fac5e xsa190-4.6.patch +5399accd478266047e9fada57bba1bf8 xsa191-4.6-CVE-2016-9386.patch +002cef87f605db2cd9a6ec5230685554 xsa192-CVE-2016-9382.patch +0bde9ad287f8a586fb47abc2f393287e xsa193-4.7-CVE-2016-9385.patch +03ee88fdd719a6e2cdd53b698b14bfa0 xsa195-CVE-2016-9383.patch +362e7460fa4e5db3a5e1c2a4209718cf xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch +3f66b6bb7129867f857fe25916c32d84 xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch +2800ef5a88bb0b1a394ae3a938d507f0 xsa197-4.6-qemuu-CVE-2016-9381.patch +23e70410938604dda2ade27a8b94264f xsa197-qemut-CVE-2016-9381.patch +e8d3ee1e904071920a6afbbf6a27aad2 xsa198-CVE-2016-9379-CVE-2016-9380.patch b05500e9fdcec5a076ab8817fc313ac3 xenstore_client_transaction_fix.patch de1a3db370b87cfb0bddb51796b50315 qemu-coroutine-gthread.patch 08bfdf8caff5d631f53660bf3fd4edaf qemu-xen_paths.patch @@ -312,6 +330,15 @@ f2082a36d968a47e477bb5082d0e0aaa58e6cb3dc20b26389f043a9b7b595fa6 xsa186-0001-x8 be9fe85d36c2c1fbca246c1f4d834c3ef11b6ab3d5467da0ac8c079aa5a68de9 xsa187-4.7-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg.patch b96731379ea77d49ffff31d969f4742dde985ef7a86af9422dcac8327c2a1916 xsa187-4.6-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch dbfc4b36132c841959847dfbb85a188ee6489ad3b8d7ecec43c55a303a43df21 xsa190-4.6.patch +d95a1f0dd5c45497ca56e2e1390fc688bf0a4a7a7fd10c65ae25b4bbb3353b69 xsa191-4.6-CVE-2016-9386.patch +687b0216eefd5ecef8a3135cc6f542cb3d9ff35e8e9696a157703e84656c35e8 xsa192-CVE-2016-9382.patch +f1b0092c585ebffe83d6ed7df94885ec5dfcb4227bdb33f421bad9febb8135a1 xsa193-4.7-CVE-2016-9385.patch +6ab5f13b81e3bbf6096020f4c3beeffaff67a075cab67e033ba27d199b41cec1 xsa195-CVE-2016-9383.patch +c4122280f3786416231ae5f0660123446d29e9ac5cd3ffb92784ed36edeec8b7 xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch +25671c44c746d4d0e8f7e2b109926c013b440e0bf225156282052ec38536e347 xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch +6f43a62d0bf9d9eaa9a13262281878d60154b6e2793047e84791418b5621f67a xsa197-4.6-qemuu-CVE-2016-9381.patch +d3af265879196c05b3fdd2cdeb5e95446f454dd3c1151452fe4f3389eccc39e4 xsa197-qemut-CVE-2016-9381.patch +0e4533ad2157c03ab309bd12a54f5ff325f03edbe97f23c60a16a3f378c75eae xsa198-CVE-2016-9379-CVE-2016-9380.patch c9691bd43a87a939d9a883279813c405eb5ac428a4f4f89e8eef01fbb4d2d6d1 xenstore_client_transaction_fix.patch 3941f99b49c7e8dafc9fae8aad2136a14c6d84533cd542cc5f1040a41ef7c6fe qemu-coroutine-gthread.patch e4e5e838e259a3116978aabbcebc1865a895179a7fcbf4bad195c83e9b4c0f98 qemu-xen_paths.patch @@ -354,6 +381,15 @@ bf899dde20cee730598b90e0a07941155b20e0ea17b9a3017a53bd0e1495fb6e5dc251934e01d029 d85bc3c56805ff5b3df6b85b2b34ff97d15fe254fc5a873b5c43c2c15564eea42753723a6296292a543e7b7dc83ad71f0fafe01fa6a6ebf82fa0a7268fc67486 xsa187-4.7-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg.patch 63f30d4a6842fc516d33334b25806e10a89228fec32315df27c9c271303d02619be4a88e638e41920ad808215280c3fce697574d05c5fb3f184844069383a201 xsa187-4.6-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch ba155f6ee81718ecaa2289998c8204e2f6ba9a6d70b042a3eaa9373d8dcd030091feca829b51914f0071d6672fad5a3f9c253da579780aa429b51c24c0bf228c xsa190-4.6.patch +502f50bece05d52b127c497eda0236a9011e56885fb0b5fac74ab449c2eac94d0f2cf64da16808c25f8a3091aef0a9586ad5c19f6b98a8c459908149d629b321 xsa191-4.6-CVE-2016-9386.patch +13670f640f36d216b276dc4fcf73745cb81e54381afbee7452d8e058166a468dc4467dbdeb3e22154f66d5ef70b796f0a0f0f0080dcb4c3587d7f15fe7b9abc6 xsa192-CVE-2016-9382.patch +6a20d6b192849af32e7db59f61d7686cbd4e0542741f3b6ddef2133f102212ba3ebc93901e5d74cdd54747e188a4eb8060b8843c10878e3bc9c567af678a6bd1 xsa193-4.7-CVE-2016-9385.patch +2b32a360c13590f24de8ebb1cd18eb17eada444034a394739c21306be708ba5924ea1448e0d120c0f61f9472bce45e80439e3fd5779f4be72d367ce5c55b6ec0 xsa195-CVE-2016-9383.patch +d76d457343a1a2cd08d6a3fcaf063569638862d5491c5eb3100bc3902d3f4845c5a9a6ceed16e2be405ecfc924d786e7a0e2407c002c59da344a10e8e183e758 xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch +3f47f78f83f01af57c51eee5c6a51466c59d23ddcbbf0c107539166840faed756af113b139c73aea74534ebceb304c0b6b69a394e47c3a9a5499342cce6d5cf8 xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch +207d73265b27dd1a3ba31b8cf3b940955f01bd4c3c61b9272a08d280d6289fda85190cce861d9c95dad085275e82899bf5e790b3856c20215cec06cfa16bcf89 xsa197-4.6-qemuu-CVE-2016-9381.patch +3edd70e047df0c452be5c0b0f3d03d041810728c9950a4f3e87f12ed27f152d56dee259794423776f42980a396039609c5563ff7e90109c7c237efab049e8e39 xsa197-qemut-CVE-2016-9381.patch +b61429fbf4d1677a8dab2710ab21335f18b3f998f2e5e19e45a4727f71b9671b3d1bd709bef3594cbaa5a47f339c3b8a5cccf11dd361b993aa76d242b825549c xsa198-CVE-2016-9379-CVE-2016-9380.patch 69dfa60628ca838678862383528654ecbdf4269cbb5c9cfb6b84d976202a8dea85d711aa65a52fa1b477fb0b30604ca70cf1337192d6fb9388a08bbe7fe56077 xenstore_client_transaction_fix.patch c3c46f232f0bd9f767b232af7e8ce910a6166b126bd5427bb8dc325aeb2c634b956de3fc225cab5af72649070c8205cc8e1cab7689fc266c204f525086f1a562 qemu-coroutine-gthread.patch 1936ab39a1867957fa640eb81c4070214ca4856a2743ba7e49c0cd017917071a9680d015f002c57fa7b9600dbadd29dcea5887f50e6c133305df2669a7a933f3 qemu-xen_paths.patch diff --git a/main/xen/xsa191-4.6-CVE-2016-9386.patch b/main/xen/xsa191-4.6-CVE-2016-9386.patch new file mode 100644 index 0000000..d661d0c --- /dev/null +++ b/main/xen/xsa191-4.6-CVE-2016-9386.patch @@ -0,0 +1,138 @@ +From: Andrew Cooper +Subject: x86/hvm: Fix the handling of non-present segments + +In 32bit, the data segments may be NULL to indicate that the segment is +ineligible for use. In both 32bit and 64bit, the LDT selector may be NULL to +indicate that the entire LDT is ineligible for use. However, nothing in Xen +actually checks for this condition when performing other segmentation +checks. (Note however that limit and writeability checks are correctly +performed). + +Neither Intel nor AMD specify the exact behaviour of loading a NULL segment. +Experimentally, AMD zeroes all attributes but leaves the base and limit +unmodified. Intel zeroes the base, sets the limit to 0xfffffff and resets the +attributes to just .G and .D/B. + +The use of the segment information in the VMCB/VMCS is equivalent to a native +pipeline interacting with the segment cache. The present bit can therefore +have a subtly different meaning, and it is now cooked to uniformly indicate +whether the segment is usable or not. + +GDTR and IDTR don't have access rights like the other segments, but for +consistency, they are treated as being present so no special casing is needed +elsewhere in the segmentation logic. + +AMD hardware does not consider the present bit for %cs and %tr, and will +function as if they were present. They are therefore unconditionally set to +present when reading information from the VMCB, to maintain the new meaning of +usability. + +Intel hardware has a separate unusable bit in the VMCS segment attributes. +This bit is inverted and stored in the present field, so the hvm code can work +with architecturally-common state. + +This is XSA-191. + +Signed-off-by: Andrew Cooper +Reviewed-by: Jan Beulich + +--- a/xen/arch/x86/hvm/hvm.c ++++ b/xen/arch/x86/hvm/hvm.c +@@ -3666,6 +3666,10 @@ int hvm_virtual_to_linear_addr( + * COMPATIBILITY MODE: Apply segment checks and add base. + */ + ++ /* Segment not valid for use (cooked meaning of .p)? */ ++ if ( !reg->attr.fields.p ) ++ return 0; ++ + switch ( access_type ) + { + case hvm_access_read: +@@ -3871,6 +3875,10 @@ static int hvm_load_segment_selector( + hvm_get_segment_register( + v, (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr, &desctab); + ++ /* Segment not valid for use (cooked meaning of .p)? */ ++ if ( !desctab.attr.fields.p ) ++ goto fail; ++ + /* Check against descriptor table limit. */ + if ( ((sel & 0xfff8) + 7) > desctab.limit ) + goto fail; +--- a/xen/arch/x86/hvm/svm/svm.c ++++ b/xen/arch/x86/hvm/svm/svm.c +@@ -620,6 +620,7 @@ static void svm_get_segment_register(str + { + case x86_seg_cs: + memcpy(reg, &vmcb->cs, sizeof(*reg)); ++ reg->attr.fields.p = 1; + reg->attr.fields.g = reg->limit > 0xFFFFF; + break; + case x86_seg_ds: +@@ -653,13 +654,16 @@ static void svm_get_segment_register(str + case x86_seg_tr: + svm_sync_vmcb(v); + memcpy(reg, &vmcb->tr, sizeof(*reg)); ++ reg->attr.fields.p = 1; + reg->attr.fields.type |= 0x2; + break; + case x86_seg_gdtr: + memcpy(reg, &vmcb->gdtr, sizeof(*reg)); ++ reg->attr.bytes = 0x80; + break; + case x86_seg_idtr: + memcpy(reg, &vmcb->idtr, sizeof(*reg)); ++ reg->attr.bytes = 0x80; + break; + case x86_seg_ldtr: + svm_sync_vmcb(v); +--- a/xen/arch/x86/hvm/vmx/vmx.c ++++ b/xen/arch/x86/hvm/vmx/vmx.c +@@ -867,10 +867,12 @@ void vmx_get_segment_register(struct vcp + reg->sel = sel; + reg->limit = limit; + +- reg->attr.bytes = (attr & 0xff) | ((attr >> 4) & 0xf00); +- /* Unusable flag is folded into Present flag. */ +- if ( attr & (1u<<16) ) +- reg->attr.fields.p = 0; ++ /* ++ * Fold VT-x representation into Xen's representation. The Present bit is ++ * unconditionally set to the inverse of unusable. ++ */ ++ reg->attr.bytes = ++ (!(attr & (1u << 16)) << 7) | (attr & 0x7f) | ((attr >> 4) & 0xf00); + + /* Adjust for virtual 8086 mode */ + if ( v->arch.hvm_vmx.vmx_realmode && seg <= x86_seg_tr +@@ -950,11 +952,11 @@ static void vmx_set_segment_register(str + } + } + +- attr = ((attr & 0xf00) << 4) | (attr & 0xff); +- +- /* Not-present must mean unusable. */ +- if ( !reg->attr.fields.p ) +- attr |= (1u << 16); ++ /* ++ * Unfold Xen representation into VT-x representation. The unusable bit ++ * is unconditionally set to the inverse of present. ++ */ ++ attr = (!(attr & (1u << 7)) << 16) | ((attr & 0xf00) << 4) | (attr & 0xff); + + /* VMX has strict consistency requirement for flag G. */ + attr |= !!(limit >> 20) << 15; +--- a/xen/arch/x86/x86_emulate/x86_emulate.c ++++ b/xen/arch/x86/x86_emulate/x86_emulate.c +@@ -1209,6 +1209,10 @@ protmode_load_seg( + &desctab, ctxt)) ) + return rc; + ++ /* Segment not valid for use (cooked meaning of .p)? */ ++ if ( !desctab.attr.fields.p ) ++ goto raise_exn; ++ + /* Check against descriptor table limit. */ + if ( ((sel & 0xfff8) + 7) > desctab.limit ) + goto raise_exn; diff --git a/main/xen/xsa192-CVE-2016-9382.patch b/main/xen/xsa192-CVE-2016-9382.patch new file mode 100644 index 0000000..b573a13 --- /dev/null +++ b/main/xen/xsa192-CVE-2016-9382.patch @@ -0,0 +1,64 @@ +From: Jan Beulich +Subject: x86/HVM: don't load LDTR with VM86 mode attrs during task switch + +Just like TR, LDTR is purely a protected mode facility and hence needs +to be loaded accordingly. Also move its loading to where it +architecurally belongs. + +This is XSA-192. + +Signed-off-by: Jan Beulich +Reviewed-by: Andrew Cooper +Tested-by: Andrew Cooper + +--- a/xen/arch/x86/hvm/hvm.c ++++ b/xen/arch/x86/hvm/hvm.c +@@ -2728,17 +2728,16 @@ static void hvm_unmap_entry(void *p) + } + + static int hvm_load_segment_selector( +- enum x86_segment seg, uint16_t sel) ++ enum x86_segment seg, uint16_t sel, unsigned int eflags) + { + struct segment_register desctab, cs, segr; + struct desc_struct *pdesc, desc; + u8 dpl, rpl, cpl; + bool_t writable; + int fault_type = TRAP_invalid_tss; +- struct cpu_user_regs *regs = guest_cpu_user_regs(); + struct vcpu *v = current; + +- if ( regs->eflags & X86_EFLAGS_VM ) ++ if ( eflags & X86_EFLAGS_VM ) + { + segr.sel = sel; + segr.base = (uint32_t)sel << 4; +@@ -2986,6 +2985,8 @@ void hvm_task_switch( + if ( rc != HVMCOPY_okay ) + goto out; + ++ if ( hvm_load_segment_selector(x86_seg_ldtr, tss.ldt, 0) ) ++ goto out; + + if ( hvm_set_cr3(tss.cr3, 1) ) + goto out; +@@ -3008,13 +3009,12 @@ void hvm_task_switch( + } + + exn_raised = 0; +- if ( hvm_load_segment_selector(x86_seg_ldtr, tss.ldt) || +- hvm_load_segment_selector(x86_seg_es, tss.es) || +- hvm_load_segment_selector(x86_seg_cs, tss.cs) || +- hvm_load_segment_selector(x86_seg_ss, tss.ss) || +- hvm_load_segment_selector(x86_seg_ds, tss.ds) || +- hvm_load_segment_selector(x86_seg_fs, tss.fs) || +- hvm_load_segment_selector(x86_seg_gs, tss.gs) ) ++ if ( hvm_load_segment_selector(x86_seg_es, tss.es, tss.eflags) || ++ hvm_load_segment_selector(x86_seg_cs, tss.cs, tss.eflags) || ++ hvm_load_segment_selector(x86_seg_ss, tss.ss, tss.eflags) || ++ hvm_load_segment_selector(x86_seg_ds, tss.ds, tss.eflags) || ++ hvm_load_segment_selector(x86_seg_fs, tss.fs, tss.eflags) || ++ hvm_load_segment_selector(x86_seg_gs, tss.gs, tss.eflags) ) + exn_raised = 1; + + rc = hvm_copy_to_guest_virt( diff --git a/main/xen/xsa193-4.7-CVE-2016-9385.patch b/main/xen/xsa193-4.7-CVE-2016-9385.patch new file mode 100644 index 0000000..c5486ef --- /dev/null +++ b/main/xen/xsa193-4.7-CVE-2016-9385.patch @@ -0,0 +1,68 @@ +From: Jan Beulich +Subject: x86/PV: writes of %fs and %gs base MSRs require canonical addresses + +Commit c42494acb2 ("x86: fix FS/GS base handling when using the +fsgsbase feature") replaced the use of wrmsr_safe() on these paths +without recognizing that wr{f,g}sbase() use just wrmsrl() and that the +WR{F,G}SBASE instructions also raise #GP for non-canonical input. + +Similarly arch_set_info_guest() needs to prevent non-canonical +addresses from getting stored into state later to be loaded by context +switch code. For consistency also check stack pointers and LDT base. +DR0..3, otoh, already get properly checked in set_debugreg() (albeit +we discard the error there). + +The SHADOW_GS_BASE check isn't strictly necessary, but I think we +better avoid trying the WRMSR if we know it's going to fail. + +This is XSA-193. + +Reported-by: Andrew Cooper +Signed-off-by: Jan Beulich +Reviewed-by: Andrew Cooper + +--- a/xen/arch/x86/domain.c ++++ b/xen/arch/x86/domain.c +@@ -890,7 +890,13 @@ int arch_set_info_guest( + { + if ( !compat ) + { +- if ( !is_canonical_address(c.nat->user_regs.eip) || ++ if ( !is_canonical_address(c.nat->user_regs.rip) || ++ !is_canonical_address(c.nat->user_regs.rsp) || ++ !is_canonical_address(c.nat->kernel_sp) || ++ (c.nat->ldt_ents && !is_canonical_address(c.nat->ldt_base)) || ++ !is_canonical_address(c.nat->fs_base) || ++ !is_canonical_address(c.nat->gs_base_kernel) || ++ !is_canonical_address(c.nat->gs_base_user) || + !is_canonical_address(c.nat->event_callback_eip) || + !is_canonical_address(c.nat->syscall_callback_eip) || + !is_canonical_address(c.nat->failsafe_callback_eip) ) +--- a/xen/arch/x86/traps.c ++++ b/xen/arch/x86/traps.c +@@ -2723,19 +2723,22 @@ static int emulate_privileged_op(struct + switch ( regs->_ecx ) + { + case MSR_FS_BASE: +- if ( is_pv_32bit_domain(currd) ) ++ if ( is_pv_32bit_domain(currd) || ++ !is_canonical_address(msr_content) ) + goto fail; + wrfsbase(msr_content); + v->arch.pv_vcpu.fs_base = msr_content; + break; + case MSR_GS_BASE: +- if ( is_pv_32bit_domain(currd) ) ++ if ( is_pv_32bit_domain(currd) || ++ !is_canonical_address(msr_content) ) + goto fail; + wrgsbase(msr_content); + v->arch.pv_vcpu.gs_base_kernel = msr_content; + break; + case MSR_SHADOW_GS_BASE: +- if ( is_pv_32bit_domain(currd) ) ++ if ( is_pv_32bit_domain(currd) || ++ !is_canonical_address(msr_content) ) + goto fail; + if ( wrmsr_safe(MSR_SHADOW_GS_BASE, msr_content) ) + goto fail; diff --git a/main/xen/xsa195-CVE-2016-9383.patch b/main/xen/xsa195-CVE-2016-9383.patch new file mode 100644 index 0000000..a193a5c --- /dev/null +++ b/main/xen/xsa195-CVE-2016-9383.patch @@ -0,0 +1,45 @@ +From: Jan Beulich +Subject: x86emul: fix huge bit offset handling + +We must never chop off the high 32 bits. + +This is XSA-195. + +Reported-by: George Dunlap +Signed-off-by: Jan Beulich +Reviewed-by: Andrew Cooper + +--- a/xen/arch/x86/x86_emulate/x86_emulate.c ++++ b/xen/arch/x86/x86_emulate/x86_emulate.c +@@ -2549,6 +2549,12 @@ x86_emulate( + else + { + /* ++ * Instructions such as bt can reference an arbitrary offset from ++ * their memory operand, but the instruction doing the actual ++ * emulation needs the appropriate op_bytes read from memory. ++ * Adjust both the source register and memory operand to make an ++ * equivalent instruction. ++ * + * EA += BitOffset DIV op_bytes*8 + * BitOffset = BitOffset MOD op_bytes*8 + * DIV truncates towards negative infinity. +@@ -2560,14 +2566,15 @@ x86_emulate( + src.val = (int32_t)src.val; + if ( (long)src.val < 0 ) + { +- unsigned long byte_offset; +- byte_offset = op_bytes + (((-src.val-1) >> 3) & ~(op_bytes-1)); ++ unsigned long byte_offset = ++ op_bytes + (((-src.val - 1) >> 3) & ~(op_bytes - 1L)); ++ + ea.mem.off -= byte_offset; + src.val = (byte_offset << 3) + src.val; + } + else + { +- ea.mem.off += (src.val >> 3) & ~(op_bytes - 1); ++ ea.mem.off += (src.val >> 3) & ~(op_bytes - 1L); + src.val &= (op_bytes << 3) - 1; + } + } diff --git a/main/xen/xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch b/main/xen/xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch new file mode 100644 index 0000000..7193e9a --- /dev/null +++ b/main/xen/xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject-CVE-2016-9377.patch @@ -0,0 +1,61 @@ +From: Andrew Cooper +Subject: x86/emul: Correct the IDT entry calculation in inject_swint() + +The logic, as introduced in c/s 36ebf14ebe "x86/emulate: support for emulating +software event injection" is buggy. The size of an IDT entry depends on long +mode being active, not the width of the code segment currently in use. + +In particular, this means that a compatibility code segment which hits +emulation for software event injection will end up using an incorrect offset +in the IDT for DPL/Presence checking. In practice, this only occurs on old +AMD hardware lacking NRip support; all newer AMD hardware, and all Intel +hardware bypass this path in the emulator. + +While here, fix a minor issue with reading the IDT entry. The return value +from ops->read() wasn't checked, but in reality the only failure case is if a +pagefault occurs. This is not a realistic problem as the kernel will almost +certainly crash with a double fault if this setup actually occured. + +This is part of XSA-196. + +Signed-off-by: Andrew Cooper +Reviewed-by: Jan Beulich +--- + xen/arch/x86/x86_emulate/x86_emulate.c | 15 +++++++++++---- + 1 file changed, 11 insertions(+), 4 deletions(-) + +diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c +index 7a707dc..f74aa8f 100644 +--- a/xen/arch/x86/x86_emulate/x86_emulate.c ++++ b/xen/arch/x86/x86_emulate/x86_emulate.c +@@ -1630,10 +1630,16 @@ static int inject_swint(enum x86_swint_type type, + { + if ( !in_realmode(ctxt, ops) ) + { +- unsigned int idte_size = (ctxt->addr_size == 64) ? 16 : 8; +- unsigned int idte_offset = vector * idte_size; ++ unsigned int idte_size, idte_offset; + struct segment_register idtr; + uint32_t idte_ctl; ++ int lm = in_longmode(ctxt, ops); ++ ++ if ( lm < 0 ) ++ return X86EMUL_UNHANDLEABLE; ++ ++ idte_size = lm ? 16 : 8; ++ idte_offset = vector * idte_size; + + /* icebp sets the External Event bit despite being an instruction. */ + error_code = (vector << 3) | ECODE_IDT | +@@ -1661,8 +1667,9 @@ static int inject_swint(enum x86_swint_type type, + * Should strictly speaking read all 8/16 bytes of an entry, + * but we currently only care about the dpl and present bits. + */ +- ops->read(x86_seg_none, idtr.base + idte_offset + 4, +- &idte_ctl, sizeof(idte_ctl), ctxt); ++ if ( (rc = ops->read(x86_seg_none, idtr.base + idte_offset + 4, ++ &idte_ctl, sizeof(idte_ctl), ctxt)) ) ++ goto done; + + /* Is this entry present? */ + if ( !(idte_ctl & (1u << 15)) ) diff --git a/main/xen/xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch b/main/xen/xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch new file mode 100644 index 0000000..26580ff --- /dev/null +++ b/main/xen/xsa196-0002-x86-svm-Fix-injection-of-software-interrupts-CVE-2016-9378.patch @@ -0,0 +1,76 @@ +From: Andrew Cooper +Subject: x86/svm: Fix injection of software interrupts + +The non-NextRip logic in c/s 36ebf14eb "x86/emulate: support for emulating +software event injection" was based on an older version of the AMD software +manual. The manual was later corrected, following findings from that series. + +I took the original wording of "not supported without NextRIP" to mean that +X86_EVENTTYPE_SW_INTERRUPT was not eligible for use. It turns out that this +is not the case, and the new wording is clearer on the matter. + +Despite testing the original patch series on non-NRip hardware, the +swint-emulation XTF test case focuses on the debug vectors; it never ended up +executing an `int $n` instruction for a vector which wasn't also an exception. + +During a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector +check to ensure that it is only used with exception vectors. Xen's use of +X86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD +hardware. + +Fix this by always using X86_EVENTTYPE_SW_INTERRUPT. + +Print and decode the eventinj information in svm_vmcb_dump(), as it has +several invalid combinations which cause vmentry failures. + +This is part of XSA-196. + +Signed-off-by: Andrew Cooper +Reviewed-by: Jan Beulich +--- + xen/arch/x86/hvm/svm/svm.c | 13 +++++-------- + xen/arch/x86/hvm/svm/svmdebug.c | 4 ++++ + 2 files changed, 9 insertions(+), 8 deletions(-) + +diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c +index 4391744..76efc3e 100644 +--- a/xen/arch/x86/hvm/svm/svm.c ++++ b/xen/arch/x86/hvm/svm/svm.c +@@ -1231,17 +1231,14 @@ static void svm_inject_trap(const struct hvm_trap *trap) + { + case X86_EVENTTYPE_SW_INTERRUPT: /* int $n */ + /* +- * Injection type 4 (software interrupt) is only supported with +- * NextRIP support. Without NextRIP, the emulator will have performed +- * DPL and presence checks for us. ++ * Software interrupts (type 4) cannot be properly injected if the ++ * processor doesn't support NextRIP. Without NextRIP, the emulator ++ * will have performed DPL and presence checks for us, and will have ++ * moved eip forward if appropriate. + */ + if ( cpu_has_svm_nrips ) +- { + vmcb->nextrip = regs->eip + _trap.insn_len; +- event.fields.type = X86_EVENTTYPE_SW_INTERRUPT; +- } +- else +- event.fields.type = X86_EVENTTYPE_HW_EXCEPTION; ++ event.fields.type = X86_EVENTTYPE_SW_INTERRUPT; + break; + + case X86_EVENTTYPE_PRI_SW_EXCEPTION: /* icebp */ +diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c +index ded5d19..f93dfed 100644 +--- a/xen/arch/x86/hvm/svm/svmdebug.c ++++ b/xen/arch/x86/hvm/svm/svmdebug.c +@@ -48,6 +48,10 @@ void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb) + vmcb->tlb_control, + (unsigned long long)vmcb->_vintr.bytes, + (unsigned long long)vmcb->interrupt_shadow); ++ printk("eventinj %016"PRIx64", valid? %d, ec? %d, type %u, vector %#x\n", ++ vmcb->eventinj.bytes, vmcb->eventinj.fields.v, ++ vmcb->eventinj.fields.ev, vmcb->eventinj.fields.type, ++ vmcb->eventinj.fields.vector); + printk("exitcode = %#Lx exitintinfo = %#Lx\n", + (unsigned long long)vmcb->exitcode, + (unsigned long long)vmcb->exitintinfo.bytes); diff --git a/main/xen/xsa197-4.6-qemuu-CVE-2016-9381.patch b/main/xen/xsa197-4.6-qemuu-CVE-2016-9381.patch new file mode 100644 index 0000000..e59a965 --- /dev/null +++ b/main/xen/xsa197-4.6-qemuu-CVE-2016-9381.patch @@ -0,0 +1,63 @@ +From: Jan Beulich +Subject: xen: fix ioreq handling + +Avoid double fetches and bounds check size to avoid overflowing +internal variables. + +This is XSA-197. + +Reported-by: yanghongke +Signed-off-by: Jan Beulich +Reviewed-by: Stefano Stabellini + +--- a/tools/qemu-xen/xen-hvm.c ++++ b/tools/qemu-xen/xen-hvm.c +@@ -817,6 +817,10 @@ static void cpu_ioreq_pio(ioreq_t *req) + { + uint32_t i; + ++ if (req->size > sizeof(uint32_t)) { ++ hw_error("PIO: bad size (%u)", req->size); ++ } ++ + if (req->dir == IOREQ_READ) { + if (!req->data_is_ptr) { + req->data = do_inp(req->addr, req->size); +@@ -846,6 +850,10 @@ static void cpu_ioreq_move(ioreq_t *req) + { + uint32_t i; + ++ if (req->size > sizeof(req->data)) { ++ hw_error("MMIO: bad size (%u)", req->size); ++ } ++ + if (!req->data_is_ptr) { + if (req->dir == IOREQ_READ) { + for (i = 0; i < req->count; i++) { +@@ -999,11 +1007,13 @@ static int handle_buffered_iopage(XenIOS + req.df = 1; + req.type = buf_req->type; + req.data_is_ptr = 0; ++ xen_rmb(); + qw = (req.size == 8); + if (qw) { + buf_req = &buf_page->buf_ioreq[(rdptr + 1) % + IOREQ_BUFFER_SLOT_NUM]; + req.data |= ((uint64_t)buf_req->data) << 32; ++ xen_rmb(); + } + + handle_ioreq(state, &req); +@@ -1034,7 +1044,11 @@ static void cpu_handle_ioreq(void *opaqu + + handle_buffered_iopage(state); + if (req) { +- handle_ioreq(state, req); ++ ioreq_t copy = *req; ++ ++ xen_rmb(); ++ handle_ioreq(state, ©); ++ req->data = copy.data; + + if (req->state != STATE_IOREQ_INPROCESS) { + fprintf(stderr, "Badness in I/O request ... not in service?!: " diff --git a/main/xen/xsa197-qemut-CVE-2016-9381.patch b/main/xen/xsa197-qemut-CVE-2016-9381.patch new file mode 100644 index 0000000..3f55bec --- /dev/null +++ b/main/xen/xsa197-qemut-CVE-2016-9381.patch @@ -0,0 +1,65 @@ +From: Jan Beulich +Subject: xen: fix ioreq handling + +Avoid double fetches and bounds check size to avoid overflowing +internal variables. + +This is XSA-197. + +Reported-by: yanghongke +Signed-off-by: Jan Beulich +Reviewed-by: Ian Jackson + +--- a/tools/qemu-xen-traditional/i386-dm/helper2.c ++++ b/tools/qemu-xen-traditional/i386-dm/helper2.c +@@ -375,6 +375,11 @@ static void cpu_ioreq_pio(CPUState *env, + { + uint32_t i; + ++ if (req->size > sizeof(unsigned long)) { ++ fprintf(stderr, "PIO: bad size (%u)\n", req->size); ++ exit(-1); ++ } ++ + if (req->dir == IOREQ_READ) { + if (!req->data_is_ptr) { + req->data = do_inp(env, req->addr, req->size); +@@ -404,6 +409,11 @@ static void cpu_ioreq_move(CPUState *env + { + uint32_t i; + ++ if (req->size > sizeof(req->data)) { ++ fprintf(stderr, "MMIO: bad size (%u)\n", req->size); ++ exit(-1); ++ } ++ + if (!req->data_is_ptr) { + if (req->dir == IOREQ_READ) { + for (i = 0; i < req->count; i++) { +@@ -516,11 +526,13 @@ static int __handle_buffered_iopage(CPUS + req.df = 1; + req.type = buf_req->type; + req.data_is_ptr = 0; ++ xen_rmb(); + qw = (req.size == 8); + if (qw) { + buf_req = &buffered_io_page->buf_ioreq[(rdptr + 1) % + IOREQ_BUFFER_SLOT_NUM]; + req.data |= ((uint64_t)buf_req->data) << 32; ++ xen_rmb(); + } + + __handle_ioreq(env, &req); +@@ -552,7 +564,11 @@ static void cpu_handle_ioreq(void *opaqu + + __handle_buffered_iopage(env); + if (req) { +- __handle_ioreq(env, req); ++ ioreq_t copy = *req; ++ ++ xen_rmb(); ++ __handle_ioreq(env, ©); ++ req->data = copy.data; + + if (req->state != STATE_IOREQ_INPROCESS) { + fprintf(logfile, "Badness in I/O request ... not in service?!: " diff --git a/main/xen/xsa198-CVE-2016-9379-CVE-2016-9380.patch b/main/xen/xsa198-CVE-2016-9379-CVE-2016-9380.patch new file mode 100644 index 0000000..dbf7084 --- /dev/null +++ b/main/xen/xsa198-CVE-2016-9379-CVE-2016-9380.patch @@ -0,0 +1,62 @@ +From 71a389ae940bc52bf897a6e5becd73fd8ede94c5 Mon Sep 17 00:00:00 2001 +From: Ian Jackson +Date: Thu, 3 Nov 2016 16:37:40 +0000 +Subject: [PATCH] pygrub: Properly quote results, when returning them to the + caller: + +* When the caller wants sexpr output, use `repr()' + This is what Xend expects. + + The returned S-expressions are now escaped and quoted by Python, + generally using '...'. Previously kernel and ramdisk were unquoted + and args was quoted with "..." but without proper escaping. This + change may break toolstacks which do not properly dequote the + returned S-expressions. + +* When the caller wants "simple" output, crash if the delimiter is + contained in the returned value. + + With --output-format=simple it does not seem like this could ever + happen, because the bootloader config parsers all take line-based + input from the various bootloader config files. + + With --output-format=simple0, this can happen if the bootloader + config file contains nul bytes. + +This is XSA-198. + +Signed-off-by: Ian Jackson +Tested-by: Ian Jackson +Reviewed-by: Andrew Cooper +--- + tools/pygrub/src/pygrub | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub +index 40f9584..dd0c8f7 100755 +--- a/tools/pygrub/src/pygrub ++++ b/tools/pygrub/src/pygrub +@@ -721,14 +721,17 @@ def sniff_netware(fs, cfg): + return cfg + + def format_sxp(kernel, ramdisk, args): +- s = "linux (kernel %s)" % kernel ++ s = "linux (kernel %s)" % repr(kernel) + if ramdisk: +- s += "(ramdisk %s)" % ramdisk ++ s += "(ramdisk %s)" % repr(ramdisk) + if args: +- s += "(args \"%s\")" % args ++ s += "(args %s)" % repr(args) + return s + + def format_simple(kernel, ramdisk, args, sep): ++ for check in (kernel, ramdisk, args): ++ if check is not None and sep in check: ++ raise RuntimeError, "simple format cannot represent delimiter-containing value" + s = ("kernel %s" % kernel) + sep + if ramdisk: + s += ("ramdisk %s" % ramdisk) + sep +-- +2.1.4 + -- 2.8.3 --------------8602A576E307371162FD1B81-- --- Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org Help: alpine-aports+help@lists.alpinelinux.org ---