UPDATES IN VERSION 5
====================
New final patch, addressing a hypervisor crash the original fix caused,
which by itself represents another security issue (DoS).
http://openwall.com/lists/oss-security/2017/11/15/4
---
main/xen/APKBUILD | 8 +++--
main/xen/{xsa243.patch => xsa243-1.patch} | 0
main/xen/xsa243-2.patch | 54 +++++++++++++++++++++++++++++++
3 files changed, 59 insertions(+), 3 deletions(-)
rename main/xen/{xsa243.patch => xsa243-1.patch} (100%)
create mode 100644 main/xen/xsa243-2.patch
diff --git a/main/xen/APKBUILD b/main/xen/APKBUILD
index 158d755dba..19d4fbd78e 100644
--- a/main/xen/APKBUILD
+++ b/main/xen/APKBUILD
@@ -3,7 +3,7 @@
# Maintainer: William Pitcock <nenolod@dereferenced.org>
pkgname=xen
pkgver=4.9.0
-pkgrel=7
+pkgrel=8
pkgdesc="Xen hypervisor"
url="http://www.xen.org/"
arch="x86_64 armhf aarch64"
@@ -167,7 +167,8 @@ source="https://downloads.xenproject.org/release/$pkgname/$pkgver/$pkgname-$pkgv
xsa240-2.patch
xsa241-4.9.patch
xsa242-4.9.patch
- xsa243.patch
+ xsa243-1.patch
+ xsa243-2.patch
xsa244.patch
xsa245-1.patch
xsa245-2.patch
@@ -453,7 +454,8 @@ e209e629757b3471eae415913c34c662882172daad634083ee29823c2cb3f00e98886352085c1afc
344519cd83ad13245de0e183b7afe564597b30d20756e44f98c0a00df55020d7ef85b92e71701c9791842a48cec93e0fcb9bfba2443313b3aafd8d21ea36abf4 xsa240-2.patch
560d8062b5683b6533a67eebafdd81e6a9d2c9194cc9f9b1404544503238d4f1d98bccb1afac477f6a55ffbc67cf9629a43fd67a745ca9093e2adc0478dd0ddb xsa241-4.9.patch
86aa763949ca36a36120a40eafbdf3a8e8bc04acd32ee6bc1e3ae90b189b86b9b166b81a9e0a4f86a7eb1fcc8723ae8ba6bd0f84fa9732e7e4e1ccea45d0b7c1 xsa242-4.9.patch
-9f269e262aa67ff9a304ed6fc64ee9c5c9f6fd606d520fc2614cd173cddc9735ad42f91a97b91f1b9c5368d54d514820937edd0ce302dc3839b426398dc6b700 xsa243.patch
+9f269e262aa67ff9a304ed6fc64ee9c5c9f6fd606d520fc2614cd173cddc9735ad42f91a97b91f1b9c5368d54d514820937edd0ce302dc3839b426398dc6b700 xsa243-1.patch
+8aaf0599259b1ff34171684467089da4a26af8fe67eedf22066955b34b2460c45abdf0f19a5a5e3dd3231b944674c62b9d3112ad7d765afc4bdbcdcfbad226e1 xsa243-2.patch
0fd35e74be6f049f1f376aa8295b14f57b92f5e45e7487e5b485c2b8f6faa2950d0fe7d8a863692b3dab8a3a7ef1d9dd94be2c6b55d01802b0d86c84d2fa9e29 xsa244.patch
b19197934e8685fc2af73f404b5c8cbed66d9241e5ff902d1a77fdc227e001a13b775a53d6e303d5f27419f5590561c84ec69409152d9773a5e6050c16e92f1b xsa245-1.patch
75369673232b2107b59dc0242d6fc224c016b9dcbf3299eab90a1d7c365d617fbc91f7b25075b394fee92782db37ce83c416387fa5ad4c4fcd51d0775a8a754f xsa245-2.patch
diff --git a/main/xen/xsa243.patch b/main/xen/xsa243-1.patch
similarity index 100%
rename from main/xen/xsa243.patch
rename to main/xen/xsa243-1.patch
diff --git a/main/xen/xsa243-2.patch b/main/xen/xsa243-2.patch
new file mode 100644
index 0000000000..1aca5d3dbd
--- /dev/null
+++ b/main/xen/xsa243-2.patch
@@ -0,0 +1,54 @@
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+Subject: x86/shadow: correct SH_LINEAR mapping detection in sh_guess_wrmap()
+
+The fix for XSA-243 / CVE-2017-15592 (c/s bf2b4eadcf379) introduced a change
+in behaviour for sh_guest_wrmap(), where it had to cope with no shadow linear
+mapping being present.
+
+As the name suggests, guest_vtable is a mapping of the guests pagetable, not
+Xen's pagetable, meaning that it isn't the pagetable we need to check for the
+shadow linear slot in.
+
+The practical upshot is that a shadow HVM vcpu which switches into 4-level
+paging mode, with an L4 pagetable that contains a mapping which aliases Xen's
+SH_LINEAR_PT_VIRT_START will fool the safety check for whether a SHADOW_LINEAR
+mapping is present. As the check passes (when it should have failed), Xen
+subsequently falls over the missing mapping with a pagefault such as:
+
+ (XEN) Pagetable walk from ffff8140a0503880:
+ (XEN) L4[0x102] = 000000046c218063 ffffffffffffffff
+ (XEN) L3[0x102] = 000000046c218063 ffffffffffffffff
+ (XEN) L2[0x102] = 000000046c218063 ffffffffffffffff
+ (XEN) L1[0x103] = 0000000000000000 ffffffffffffffff
+
+This is part of XSA-243.
+
+Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Reviewed-by: Tim Deegan <tim@xen.org>
+
+--- a/xen/arch/x86/mm/shadow/multi.c
++++ b/xen/arch/x86/mm/shadow/multi.c
+@@ -4350,11 +4350,18 @@ static int sh_guess_wrmap(struct vcpu *v
+
+ /* Carefully look in the shadow linear map for the l1e we expect */
+ #if SHADOW_PAGING_LEVELS >= 4
+- /* Is a shadow linear map is installed in the first place? */
+- sl4p = v->arch.paging.shadow.guest_vtable;
+- sl4p += shadow_l4_table_offset(SH_LINEAR_PT_VIRT_START);
+- if ( !(shadow_l4e_get_flags(*sl4p) & _PAGE_PRESENT) )
+- return 0;
++ /*
++ * Non-external guests (i.e. PV) have a SHADOW_LINEAR mapping from the
++ * moment their shadows are created. External guests (i.e. HVM) may not,
++ * but always have a regular linear mapping, which we can use to observe
++ * whether a SHADOW_LINEAR mapping is present.
++ */
++ if ( paging_mode_external(d) )
++ {
++ sl4p = __linear_l4_table + l4_linear_offset(SH_LINEAR_PT_VIRT_START);
++ if ( !(shadow_l4e_get_flags(*sl4p) & _PAGE_PRESENT) )
++ return 0;
++ }
+ sl4p = sh_linear_l4_table(v) + shadow_l4_linear_offset(vaddr);
+ if ( !(shadow_l4e_get_flags(*sl4p) & _PAGE_PRESENT) )
+ return 0;
--
2.15.0
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---