[3.11.y.z extended stable] Patch "xen: Fix possible user space selector corruption" has been added to staging queue

[Luis Henriques]

This is a note to let you know that I have just added a patch titled

    xen: Fix possible user space selector corruption

to the linux-3.11.y-queue branch of the 3.11.y.z extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.11.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.11.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

------

>From a05979f567d6063131ca7f503e29d22f54fd09cc Mon Sep 17 00:00:00 2001
From: Frediano Ziglio <frediano.ziglio at citrix.com>
Date: Thu, 10 Oct 2013 14:39:37 +0000
Subject: xen: Fix possible user space selector corruption

commit 7cde9b27e7b3a2e09d647bb4f6d94e842698d2d5 upstream.

Due to the way kernel is initialized under Xen is possible that the
ring1 selector used by the kernel for the boot cpu end up to be copied
to userspace leading to segmentation fault in the userspace.

Xen code in the kernel initialize no-boot cpus with correct selectors (ds
and es set to __USER_DS) but the boot one keep the ring1 (passed by Xen).
On task context switch (switch_to) we assume that ds, es and cs already
point to __USER_DS and __KERNEL_CSso these selector are not changed.

If processor is an Intel that support sysenter instruction sysenter/sysexit
is used so ds and es are not restored switching back from kernel to
userspace. In the case the selectors point to a ring1 instead of __USER_DS
the userspace code will crash on first memory access attempt (to be
precise Xen on the emulated iret used to do sysexit will detect and set ds
and es to zero which lead to GPF anyway).

Now if an userspace process call kernel using sysenter and get rescheduled
(for me it happen on a specific init calling wait4) could happen that the
ring1 selector is set to ds and es.

This is quite hard to detect cause after a while these selectors are fixed
(__USER_DS seems sticky).

Bisecting the code commit 7076aada1040de4ed79a5977dbabdb5e5ea5e249 appears
to be the first one that have this issue.

Signed-off-by: Frediano Ziglio <frediano.ziglio at citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Cc: David Vrabel <david.vrabel at citrix.com>
[ luis: backported to 3.11: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
 arch/x86/xen/smp.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index b81c88e..0cc3d8c 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -277,6 +277,15 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	   old memory can be recycled */
 	make_lowmem_page_readwrite(xen_initial_gdt);

+#ifdef CONFIG_X86_32
+	/*
+	 * Xen starts us with XEN_FLAT_RING1_DS, but linux code
+	 * expects __USER_DS
+	 */
+	loadsegment(ds, __USER_DS);
+	loadsegment(es, __USER_DS);
+#endif
+
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
--
1.9.0